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CHAPTER  1 


INTRODUCTION 


The  development  and  use  of  Geographic  Information  Systems  (GIS)  is  growing  rapidly 
as  computers  become  more  affordable  and  ever  more  powerful.  Geographic  Information  System 
developers  and  users  alike  are  faced  with  a  complex  array  of  problems  during  system  design 
including  definition  of  requirements,  development  of  specifications,  selection  of  hardware,  and 
implementation  of  the  system.  Some  have  made  poor  decisions  regarding  these  subjects  in  the 
past,  often  due  to  inadequate  input  into  the  planning  process.  Fortunately,  recent  years  have 
seen  increasing  efforts  on  the  part  of  developers,  designers,  and  users  to  utilize  structured  GIS 
design  methods  to  better  control,  define  and  model  critical  features  of  new  systems. 

The  purpose  of  this  study  is  to  examine  the  role  of  prototyping,  a  software  engineering 
concept,  in  the  GIS  design  process.  This  study  will  first  summarize  the  evolution  of  GIS  design 
methodology  to  illustrate  both  its  current  status  and  how  new  ideas  have  been  incorporated  into 
the  field.  Then  a  case  study  will  be  used  to  evaluate  the  role  that  prototyping  played  in  one  GIS 
database  development  project  and  finally  recommendations  will  be  made  for  the  further  use  of 
prototyping  in  GIS  design. 

GIS  Design  Issues 

Proper  definition  and  subsequent  satisfaction  of  user  requirements  is  the  focus  of  the  GIS 
design  process,  the  same  as  it  is  for  any  other  information  system  development.  At  present,  our 
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focus  is  upon  maximizing  the  user’s  involvement  in  the  design  of  the  GIS  in  order  to  optimize 
the  probability  of  delivering  a  workable  system.  Geographic  Information  Systems  are  seldom 
developed  from  scratch  today  and  the  result  of  the  GIS  design  process  is  most  often  oriented 
toward  the  selection  of  a  system  that  matches  the  users’  requirements  from  a  set  of  GISs  offered 
by  competing  firms.  However,  the  development  of  GIS  databases  and  applications  also  require 
substantial  levels  of  system  design  activities. 

Of  course,  insertion  of  the  human  factor  into  the  design  process  brings  forward  a  set  of 
social  and  organizational  obstacles  to  the  definition  and  implementation  of  user  requirements. 
One  way  of  coping  with  these  constraints  is  to  introduce  a  structure  into  the  GIS  design  process 
to  best  account  for  foreseeable  problems.  Calkins  (1972)  was  the  first  to  develop  a  structured 
GIS  design  process  that  was  systematic  and,  to  an  extent,  repeatable.  It  offered  general  guidance 
on  the  activities  to  be  performed  and  thereby  increased  the  chances  of  successful  GIS 
implementation .  Since  Calkins,  others  have  introduced  more  advanced  GIS  design  processes 

which  take  into  account  new  approaches  to  system  analysis.  Some  designers  have  called  for 
incorporating  specific  software  engineering  techniques  such  as  structured  system  analysis  and 
modem  database  modelling  into  GIS  development.  Although  there  was  some  early  resistance, 
these  ideas  are  now  being  readily  accepted  and  implemented. 

One  such  software  engineering  technique,  called  prototyping,  has  come  to  the  fore  in  the 
realm  of  software  system  design.  Early  on,  prototyping  in  software  development  was  used 
primarily  during  coding  operations  as  a  technique  for  the  identification  and  removal  of  design 
defects  in  software  implementation  activities  (Carey  and  Mason,  1983).  It  is  now  more  often 
defined  as  a  process  of  modelling  user  requirements  in  one  or  more  levels  of  detail,  including 
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working  models  (Pressman,  1982).  A  procedure  known  as  rapid  prototyping  illustrates  the 
greatest  advantage  of  the  prototyping  process  but  is  often  overlooked  in  system  design  projects. 
Rapid  prototyping  uses  a  rapid  pace  to  quickly  gather  information  about  initial  requirements  and 
is  a  specific  strategy  for  the  subsequent  refinement  of  user  requirements  through  modelling 
(Peters,  1981;  Connell  and  Shafer,  1989).  In  either  case,  prototyping  or  rapid  prototyping,  the 
goal  is  usually  to  derive  a  working  piece  of  software  (Pressman.  1982;  Connell  and  Shafer, 
1989). 

Given  the  tendency  of  some  in  the  GIS  field  to  resist  the  introduction  of  new  software 
engineering  techniques,  it  should  not  be  surprising  that  prototyping  is  not  wide  spread  in  GIS 
design  and  implementation.  A  notable  exception  is  the  Marble- Wilcox  GIS  Design  Model  (1991) 
which  is  explicitly  based  in  modem  software  engin^ring  methodology  and  includes  the  option 
of  utilizing  pilot  studies  to  aid  in  the  determination  of  user  requirements  in  certain  situations. 
However,  pilot  studies  are  defined  by  them  as  "a  sample  implementation  of  the  proposed  GIS 
within  a  well-defined  but  limited  test  realm"  (Marble  and  Wilcox,  1991)  which  is  intended  to 
focus  user  requirements  and  prove  that  the  initial  design  is,  at  least,  feasible.  Because  pilot 
projects  at  the  system  level  are  often  expensive  and  require  pre-selection  of  GIS  software  for 
demonstration  purposes,  they  are  not  frequently  performed. 

Although  pilot  studies  in  GIS  design  and  prototyping  in  software  engineering  can  both 
be  utilized  to  focus  user  requirements,  there  are  subtle  differences  between  them.  Pilot  studies 
work  toward  a  larger  goal,  that  is  the  refinement  of  the  proposed  system  configuration,  by 
assessing  the  required  user  functions,  costs,  data  availability,  and  by  taking  a  first  look  at 
performance  requirements  in  a  sample  implementation.  Conclusions  from  the  sample  implemen- 
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tation  are  used  to  refine  the  requirements  analysis  process  and  the  system  design  and 
specification  documents.  Prototyping  in  software  engineering  is  commonly  focused  upon  the 
implementation  of  a  piece  of  software.  Several  iterations  of  the  prototyping  cycle  usually  lead 
to  a  running  version  of  the  software,  ready  for  release  (Pressman,  1982). 

While  much  has  been  written  about  the  importance  of  involving  users  in  the  design  and 
implementation  c  GISs,  there  is  a  pressing  need  to  learn  more  about  the  way  in  which  GIS  users 
and  developers  interact  during  the  design  of  a  Geographic  Information  System.  There  ’■"'ve  been 
few  efforts  to  document  the  results  of  the  system  design  process  in  Geographic  Information 
System  development,  regardless  of  methodologies  used.  In  most  instances,  developers  are 
content  to  conduct  the  design  and  implementation  work,  with  or  without  the  user’s  active 
involvement,  deliver  a  system,  and  then  go  about  their  business.  Their  concern  is  not  whether 
the  specifications  were  adequate  but  whether  they  were  available.  Once  the  system  is  in  ihe 
user’s  hands  it  is  no  longer  one  of  the  designer’s  top  priorities. 

Peuquet  and  Bacastow’s  recent  article  (1992)  is  one  attempt  to  record  the  results  of  the 
design  process.  They  show  how  the  organizational  context  of  the  U.S.  Army’s  effort  to  develop 
a  GIS  has  prevented  successful  implementation  to  date;  technological  issues  have  proven  to  be 
less  of  a  hindrance.  They  recommend  the  use  of  iterative  prototyping  as  a  way  of  overcoming 
obstacles  in  satisfying  user  requirements.  While  prototyping  is  not  new  to  many  disciplines, 
especially  the  engineering  fields,  it  is  not  widely  used  in  the  development  of  GISs.  One  can  find 
few  references  to  projects  where  prototyping  has  been  used;  those  that  do  exist  are  primarily  in 
the  Management  Information  System  design  literature  (Connell  and  Shafer,  1989).  One 
significant  case  that  does  exist  within  the  realm  of  GIS  design  is  the  Defense  Mapping  Agency’s 
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(DMA)  Digital  Chart  of  the  World  (DCW)  database  development  project.  Examination  of  this 
case  can  provide  a  good  starting  point  for  further  investigation  into  the  use  of  prototyping  to 
enhance  CIS  design  methodologies. 


Problem 

Given  the  importance  of  user  involvement  in  the  GIS  design  model,  the  traditional  form 
of  design  methods  such  as  structured  analysis  and  the  Marble-Wilcox  Design  Model,  and  the 
tendency  to  infrequently  rely  on  iterative  development  of  requirements,  what  role  can 
prototyping  play  in  GIS  design  and  implementation?  This  paper  will  strive  to  answer  this 
question  by  first  looking  further  at  GIS  design  issues,  the  relevance  of  prototyping  as  it  has  been 
applied  to  system  development,  and  finally  by  studying  a  case  where  prototyping  was  used  as 
a  major  tool  in  the  design  of  a  large  GIS  database. 

Overview  of  Study  Methodology  and  Scope 
After  a  review  of  current  literature  in  GIS  design  and  software  engineering  fields,  this 
study  will  present  a  descriptive  and  exploratory  case  analysis  of  the  Defense  Mapping  Agency’s 
Digital  Chart  of  the  World  development  project  to  provide  insight  into  the  GIS  design  process 
and  the  adoption  of  a  rapidly  growing  technology  (GIS)  in  the  unique  arena  of  the  Department 
of  Defense.  The  impact  of  prototyping  on  the  DCW  design  will  be  examined  in  depth.  Specific 
areas  of  concentration  will  include  an  analysis  of  the  processes  by  which  user  requirements  were 
defined  and  met,  the  problems  associated  with  the  implementation  of  prototyping,  and  how 
prototyping  may  help  the  GIS  design  process. 
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Review  of  project  documentation  and  interviews  with  personnel  involved  in  the  design, 
production,  and  evaluation  of  the  prototypes  provided  the  bulk  of  the  research  data.  Project 
documentation  was  made  available  by  the  DCW  sponsor,  the  Defense  Mapping  Agency,  and  its 
contractor.  Environmental  Systems  Research  Institute  (ESRI).  An  extensive  review  of  these 
documents  led  to  an  interview  plan  for  site  visits  to  follow  up  on  issues  discovered  during 
preliminary  research  (the  interview  plan  used  during  the  site  visits  is  contained  in  Appendix  1). 
Two  site  visits  were  conducted  to  personally  interview  major  participants  in  the  DCW 
development  project. 

The  first  visit  to  Washington,  D.C.  in  August  of  1990  was  for  the  purpose  of  contacting 
personnel  from  the  Defense  Mapping  Agency,  the  sponsor  of  the  project.  In  addition,  the 
proximity  of  various  military  commands,  services,  and  defense  agencies  in  the  D.C  area 
provided  an  additional  opportunity  to  interview  the  users  for  whom  the  product  was  being 
developed.  The  second  visit  was  conducted  at  the  Redlands,  CA  site  of  ESRI,  the  firm  doing 
the  DCW  development  work  under  contract  with  DMA.  This  visit  allowed  for  in-depth 
discussions  with  various  production  personnel  as  well  as  the  chance  to  obtain  additional 
documents  regarding  the  design  and  implementation  of  the  DCW  program.  A  list  of  persons 
contacted  for  this  study  may  be  found  in  Appendix  2. 

The  bulk  of  this  report  was  compiled  after  reviewing  the  project  documentation  and 
collating  the  vast  amounts  of  information  provided  in  the  interviews  into  a  set  of  relevant 
material.  The  organization  of  this  study  will  lead  us  through  a  process  where  we  will; 
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•  Leam  about  the  current  status  of  system  design  activities  (chapter  2); 

•  Discuss  the  case  study  of  a  GIS  database  design  project  and  highlight  factors 
important  to  our  understanding  of  the  case  (chapter  3); 

•  Examine  the  way  in  which  the  development  project  was  executed  and  how  the 
participants’  reacted  to  the  project  (chapter  4);  and 

•  Summarize  how  prototyping  may  be  used  in  GIS  design  by  looking  at 
findings,  recommendations,  and  future  work  (chapters  5  and  6). 
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CHAPTER  2 


LITERATURE  REVIEW 


The  CIS  design  literature  stresses  the  need  for  active  user  involvement  in  the  design  and 
development  of  systems,  databases  and  related  products.  There  are  many  methods  which  may 
be  used  to  accomplish  various  objectives  in  any  information  system  design  process  but  most  are 
now  structured  in  some  formal  fashion  (see  Yourdon,  1989  and  Connell  and  Shafer,  1989  for 
general  system  design;  Marble  and  Wilcox,  1991  for  a  structured  approach  to  CIS  design).  The 
use  of  prototypes  has  long  been  an  accepted  method  of  system  design  in  other  fields  but  has  not 
been  widely  recognized  inside  information  systems  development,  nor  in  CIS  design,  until 
recently.  Prototyping  elsewhere  has  demonstrated  strong  potential,  especially  in  small  project 
development. 

A  review  of  the  current  state  of  CIS  design  and  software  engineering  techniques  serves 
as  a  starting  point  for  an  investigation  into  how  prototyping  can  be  used  in  CIS  design. 

User  Needs  Analysis 

Regardless  of  the  level  of  credence  given  to  the  adoption  of  software  engineering 
techniques  in  the  CIS  design  process,  user  participation  has  been  stressed  throughout  the  1980s 
and  the  early  part  of  the  1990s  by  numerous  authors  involved  in  CIS  research  (Chrisman,  1987; 
De  Man,  1988;  Marble  and  Wilcox,  1991).  The  first  steps  of  the  Marble-Wilcox  GIS  Design 
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Model  deal  explicitly  with  defining  and  considering  the  organizational  concerns  and  user 
requirements  which  "underlie  the  entire  purpose  of  not  only  the  design  process,  but  of  the  GIS 
implementation  itselP  (Marble  and  Wilcox,  1991).  Such  studies  of  requirements  and 
organizational  impacts  are  very  complex,  not  completely  understood,  and  can  change  along  with 
the  composition  of  user  groups  in  each  project  and  with  advances  in  technology  (Eason,  1988; 
Rhind  and  Green,  1988;  Teory  and  Fry,  1982). 

It  can  be  taken  as  a  given  that  organizational  concerns  accompany  the  adoption  of  any 
new  technology  such  as  a  GIS  (see  Eason  for  a  full  discussion  of  problems  associated  with  the 
adoption  of  new  information  technology).  In  addition,  failure  to  adequately  involve  users  in  the 
system  design  process  often  leads  to  numerous,  varied,  and  complex  organizational  and 
institutional  problems.  This  second  set  of  problems  alone  often  can  cause  failure  of  an 
information  systems  development  project  (see  Lucas,  1975;  De  Man,  1988;  Eason,  1988  for 
illustrations  of  these  concerns). 

Early  identification  of  these  concerns  is  one  way  to  mitigate  the  chances  of  failure. 
Actively  involving  the  user  in  the  design  process,  including  the  definition  of  organizational 
issues,  encourages  maximum  interaction  between  designers  and  users.  This  helps  the  designers 
deliver  a  beneficial  product  and  aids  in  convincing  the  users  that  real  advantages  will  stem  from 
adoption  of  the  new  technology  (Marble  and  Wilcox,  1991).  This  also  sets  the  stage  for  a  more 
fruitful  exploration  of  user  requirements. 

There  are  many  bottlenecks  and  barriers  to  the  effective  functioning  of  an  information 
system  within  the  larger  information  utilization  system  inside  of  which  it  must  function. 
Potential  information  flows  to  and  from  the  system,  organizational  procedures  and  needs,  and 
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actual  uses  of  information  are  all  important  foci  (De  Man,  1988).  Organizational  and 
institutional  changes  often  are  required  to  handle  the  increased  emphasis  on  the  new  technology. 
De  Man  addresses  structured  approaches  to  system  design  but  goes  on  to  impugn  their  usefulness 
by  asserting  that  these  methods  are  too  rigid  and  fail  to  recognize  the  uncertainties  of  change  and 
the  dynamics  of  an  information  system’s  environment.  Lucas  (1975)  adds  a  fresh  dimension 
to  ’old  stand-by’  rules  in  his  work  on  design  strategies.  He  lists  seemingly  obvious  factors 
regarding  organizational  interaction  in  information  system  design  that  are  often  over-looked  in 
Geographic  Information  System  design.  Lucas  develops  a  descriptive  model  of  information 
systems  within  the  context  of  organizational  behavior  (focusing  on  user  attitudes  and  perceptions, 
the  use  of  systems,  and  user  performance).  The  author’s  conclusion  that  management  holds  the 
key  to  carrying  out  user-oriented  design  is  right  on  the  mark.  Good  managers  will  see  to  it  that 
the  design  activity  works  for  the  user  (Lucas,  1975),  even  in  the  rapidly  changing  environment 
De  Man  addresses.  While  the  author  makes  this  case  in  a  low-key  fashion,  the  message  is  one 
which  should  occupy  a  place  of  prominence  in  the  minds  of  all  GIS  analysts. 

Eason’s  (1988)  main  assertion  is  that  introduction  of  any  information  system  technology 
will  change  an  organization.  To  make  the  change  as  effective  as  possible,  the  organization 
should  be  altered  to  take  into  account  the  new  technology.  He  advocates  a  structured  approach 
toward  design  and  implementation  of  information  systems  to  ease  this  transformation.  There  are 
several  ways  of  doing  this  which  include  structured  design  methods,  participative  design 
methods,  and  even  end-user  developed  systems.  Eason  argues  for  a  more  "socio-technical" 
design  method  that  incorporates  some  of  the  best  features  of  each  of  the  preceding  methods. 
User-oriented  design  techniques  are  the  most  favored  method.  Eason  argues  that  in  order  for 
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an  information  system  to  work  well,  it  must  first  fulfill  the  organization’s  needs  on  a 
technological  level,  but  the  people  who  will  interact  with  the  system  must  view  it  as  an  important 
tool  which  will  aid  their  efforts.  Without  development  of  this  latter  view,  the  system  will  likely 
fail  due  to  lack  of  use  or  even  outright  sabotage  (E^n,  1988). 

After  the  decision  is  made  to  develop  or  acquire  a  new  system  and  the  relevant 
organizational  concerns  have  been  addressed,  the  formal  definition  of  user  requirements  may 
begin.  This  is  a  detailed  investigation  into  the  essential  specifications  of  what  the  system  is 
supposed  to  do  (Yourdon,  1989).  Involvement  of  the  user  can  take  many  forms  but  it  is  most 
helpful  when  designers  have  an  in-depth  understanding  of  the  user’s  actions,  data  t^sforma- 
tions,  and  work  environment.  Structured  methodologies  and  software  engineering  practices  have 
proven  invaluable  in  performing  these  tasks.  Surveys,  interviews,  and  working  sessions,  where 
the  users  actions  are  observed,  all  play  an  important  role  in  this  process.  Pilot  studies  are  highly 
useful  and  can  be  related  to  prototyping.  These  projects  allow  the  user  to  move  from  the 
"abstract  to  the  specific  in  contemplating  uses  of  the  GIS"  (Marble  and  Wilcox,  1991).  Further 
design  of  new  systems,  where  we  move  from  a  conceptual  model  of  the  system  to  a  physical 
implementation  (and  including  development  of  prototypes),  relies  heavily  upon  the  adequacy  and 
accuracy  of  these  requirements. 

Efforts  to  develop  a  GIS  design  methodology  have  closely  followed  evolution  of  software 
life  cycle  models.  Boehm’s  classic  waterfall  cycle  (1981),  Calkin’s  work,  and  modem  structured 
techniques  such  as  Yourdon’s  all  offer  this  perspective.  A  GIS  design  methodology  which  has 
been  heavily  influenced  by  software  engineering  techniques  can  best  be  represented  by  the 
Marble-Wilcox  model.  The  Marble-  Wilcox  model  is  a  traditional  step-by-step  approach  which 


11 


uses  an  iterative  cycle  to  define  useful  guidelines  in  addressing  design  and  implementation 
questions.  Figure  1  shows  the  Marble- Wilcox  model,  and  its  flow  from  the  feasibility  study  to 
the  definition  of  user  requirements,  construction  of  the  database,  development  of  system 
specifications,  and  other  critical  concerns.  The  influence  of  the  "waterfall  life  cycle  model"  and 
other  software  engineering  concepts  is  unmistakable  (it  is  also  systematic,  repeatable,  and 
flexible). 

As  affordability  and  advances  in  system  capabilities  allow  more  and  more  users  to  take 
advantage  of  GISs  on  a  wide  variety  of  computer  platforms,  broader  design  concerns  come  into 
play  such  as  how  to  construct  GIS  databases  for  a  myriad  of  users.  Very  large  spatial  databases 
are  becoming  more  feasible  as  technology  improves  and  costs  decline;  however,  issues  associated 
with  system  design  become  even  more  important  in  these  large  cases  since  small  problems  will 
be  magnified.  Epstein’s  article  in  the  book  Building  Databases  for  Global  Science  (1988) 
illustrates  the  need  for  specific  goals  when  developing  large  global  data  sets  by  outlining  some 
of  the  obstacles  to  such  a  feat.  The  fact  that  databases  do  not  exist  in  environmental  and 
conservation  forums  is  probably  due  to  the  lack  of  a  clear  and  achievable  purpose.  Epstein 
shows  that  large  sets  of  digital  information  can  indeed  be  collated  and  used  by  a  number  of 
customers  effectively  within  specific  information  regimes.  As  we  shall  see  in  the  next  section, 
it  seems  reasonable  to  assume  that  the  techniques  for  user  requirements  definition  offered  by 
structured  methods  coupled  with  prototyping  activities  may  provide  a  way  to  assimilate  the 
requirements  of  multinational  organizations  into  a  user-oriented  design  document,  thereby 
increasing  chances  of  success  in  the  development  of  a  global  database. 
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MARBLE  -  WILCOX  MODEL:  GENERAL  FLOW  DIAGRAM 

Source:  Marble  and  Wilcox,  1991 


Prototyping  in  Software  Engineering 


Prototyping  is  the  process  of  modelling  the  users’  system  requirements  by  creating 
working  models  at  increasing  levels  of  detail  (Boar,  1983).  After  models  of  the  system  are  built 
by  stepping  through  physical  implementation  activities,  the  user  may  then  review  the  design  and 
provide  feedback  to  the  process  (Pressman,  1982;  Krista  and  Rizman,  1989).  Prototyping  can 
be  used  for  mass-produced,  as  well  as  one-of-a-kind,  systems.  Mock-ups  and  prototype  models 
are  often  used  during  the  development  efforts  associated  with  many  conventional  engineering 
fields  (Peters,  1981)  whereas  software  developers  and  GIS  designers  are  seldom  trained  in  such 
a  fashion. 

The  concept  of  prototyping  in  software  engineering  has  evolved  from  an  implementation 
activity  to  one  more  focused  on  the  conceptual  stages  of  design.  Early  ideas  called  for  the  use 
of  prototypes  to  design,  implement,  test  and  bring  into  operation  a  highly  simplified  version  of 
the  system  according  to  a  defined  set  of  user  requirements.  Based  upon  the  experience  gained 
in  operating  the  first  prototype,  a  revised  requirement  was  established  and  a  second  prototype 
was  designed  and  implemented  (Bally,  Brittan,  and  Wagner,  1977).  The  activities  associated 
with  this  type  of  prototyping  include  fairly  detailed  requirements  analysis  and  system  design. 
Use  of  prototyping  in  this  fashion,  as  well  as  to  detect  and  remove  design  defects  in  coding 
operations,  is  an  implementation  activity  (Carey  and  Mason,  1983). 

Recently,  software  engineers  have  called  for  prototyping  to  be  used  as  a  specific  strategy 
for  the  definition  of  user  requirements  and  the  revision  of  those  needs  through  iterative  analysis 
activities  (Peters,  1981;  Sethi  and  Teng,  1988).  A  recent  outgrowth  of  prototyping,  known  as 
rapid  prototyping,  makes  use  of  an  accelerated  pace  to  swiftly  gather  data  about  initial  system 


14 


requirements.  This  rough  analysis  is  then  used  to  build  models  for  the  users’  review  and 
comment.  Successive  iterations  refine  and  revise  user  requirements  and  lead  to  a  system 
specification  document  for  the  final  product  (Connell  and  Shafer,  1989;  Arthur,  1992). 
Prototyping  in  this  manner,  whether  at  a  rapid  pace  or  not,  may  be  used  to  bridge  the  gap 
between  requirements  analysis  and  system  design  and  implementation. 

Peters  (1981)  argued  that  prototyping  could  be  used  to  objectively  establish  the  quality 
of  the  design  by  evaluating  user  feedback.  Some  of  the  advantages  to  this  approach,  as  put  forth 
by  Arthur  (1992)  are: 

1 .  More  effective  communication  between  designers  and  users. 

2.  Reduced  risk  of  failure  due  to  less  uncertainty. 

3.  The  ability  to  deliver  the  desired  functionality. 

4.  Serendipity  in  the  development  process  can  be  maximized. 

5.  Reduced  cycle  time  by  a  factor  of  four  or  more.’ 

6.  Fewer  defects  through  continuous  testing  and  evaluation. 

7.  Users  are  more  involved. 

Pitfalls  may  include  an  inability  to  manage  the  expectations  of  users  brought  about  by  their 
interaction  with  the  prototype  and  a  tendency  to  omit  key  players  or  to  involve  too  many 
reviewers.  Prototyping  was  greeted  by  considerable  resistance  when  first  introduced  on  a 
wide  scale  as  an  evaluation  technique  in  software  design  (Peters,  1981;  Connell  and  Shafer, 


'Arthur  (1992)  stated  that  cycle  time  "from  concept  to 
delivered  product"  may  be  reduced  by  a  factor  of  four  or  more  by 
focusing  on  creating  only  the  parts  of  the  product  that  provide  the 
most  value.  He  equates  it  to  gaining  80  percent  of  the  value  by 
expending  only  20  percent  of  the  effort  on  the  first  prototype. 
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1989),  While  computer  information  scientists  remained  unconvinced  of  its  utility  in  the  early 
1980s,  there  was  one  critical  study  where  the  advantages  and  disadvantages  of  prototyping  were 
clearly  demonstrated  (Boehm,  Gray,  and  Seewaldt,  1984).  In  this  study,  a  software  product  was 
developed  by  teams  taking  two  different  approaches;  several  teams  used  the  more  traditional 
top-down  specification  development  approach  while  the  others  used  prototyping. 

The  results  of  this  experiment  indicated  that  prototyping  offered  several  improvements 
to  the  development  process  for  software  products.  Prototyping  turned  out  products  equivalent 
to  the  specified  product  but  with  nearly  half  the  amount  of  code  and  with  nearly  half  the  effort. 
While  the  specified  product  was  somewhat  more  easily  designed,  integrated,  and  coded,  the 
prototyped  product  had  a  "more  friendly"  user  interface  and  was  easier  to  learn  how  to  use. 
However,  prototyping  required  that  more  time  be  spent  on  testing,  fixing,  and  integrating 
modules  according  to  user  feedback  rather  than  defining  requirements  (Boehm,  et  al.,  1984). 

This  study,  however,  focused  on  the  designers  of  the  software,  neglected  any  measure 
of  user  satisfaction  with  the  product,  and  paid  little  attention  to  the  costs  associated  with  the 
reviewers’  investment  in  the  process.  In  addition,  the  prototyping  process  was  geared  toward 
making  the  designers,  coders,  and  testers’  lives  easier,  not  toward  demonstrating  products  to 
users  to  aid  in  requirements  definition  and  evaluation.  Despite  recent  calls  for  the  use  of 
prototyping  as  a  requirements  analysis  and  design  technique,  software  engineers  tend  to  remain 
focused  on  implementation  activities. 

Connell  and  Shafer  (1989),  in  their  recent  volume  Structured  Rapid  Prototyping  explained 
that  prototyping  must  be  coupled  with  structured  design  methods  in  a  fast  paced  environment  to 
achieve  its  full  potential.  Their  arguments  for  tools  linking  structured  system  analysis  techniques 
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and  relational  database  management  systems  illustrate  how  software  structures  can  be  changed 
quickly  to  accommodate  user’s  reactions  to  prototypes.  The  focus  here  is  to  quickly  gain  only 
a  rough  idea  of  the  system  requirements  at  first,  construct  prototypes  using  these  tools  to  help 
the  user  better  define  their  true  needs  in  iterative  steps,  then  refine  the  design  documents  before 
moving  on  to  the  physical  implementation  of  software. 

Connell  and  Shafer’s  suggestions  provide  for  a  modified  design  life  cycle  using  data  flow 
diagrams  (DFDs),  entity-relationship  diagrams,  and  control  flow  graphs  (to  model  the  user’s 
menu  interface),  along  with  an  evolutionary  approach  to  speed  development  in  many  ways. 
Their  modified  life  cycle  is  included  as  Figure  2.  Connell  and  Shafer  argued  that  a  new  life 
cycle  approach  to  software  development  may  seem  to  call  for  conventional  activities  to  occur 
at  unconventional  times,  especially  since  the  process  is  not  sequential,  as  the  figure  implies. 
Anything  discovered  during  prototype  iteration  must  be  immediately  addressed,  wherever  it 
occurs  in  the  cycle. 

The  first  activity  in  the  Connell  and  Shafer  model  is  to  produce  a  document  of  rough 
schedules  and  deliverables  (step  1).  Next,  preliminary  interviews  with  users  are  used  to  create 
an  "intentionally  incomplete,  high-level  paper  model  of  the  system”  (Connell  and  Shafer,  1989) 
and  a  partial  requirements  specification  (step  2).  The  database,  menus,  and  functions  are  created 
in  the  next  three  steps  to  produce  a  model  for  demonstration  to  the  user.  At  this  point, 
fourth-generation  techniques  can  be  used  to  link  Computer  Assisted  Software  Engineering 
(CASE)  tools  to  Relational  Database  Management  Systems  (RDBMS)  to  develop  forms,  screens, 
menus,  and  reports  in  a  working  prototype  for  the  user’s  review  (Connell  and  Shafer,  1989). 
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Connell  and  Shafer's  Evolutionary 
Rapid  Prototyping  Process 


Figure  2 
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Source:  Connell  and  Shafer,  1989 


One  of  the  tools  used  in  Connell  and  Shafer’s  approach  to  prototype  creation  is  the 
control  flow  graph  (CFG).  CFGs  and  other  products  of  the  CASE  tool  serve  as  a  bridge 
between  requirements  analysis  and  system  design  activities.  Where  Data  Flow  Diagrams  model 
the  flow  of  the  data  and  its  transformations,  in  the  system,  CFGs  illustrate  the  user  interface  by 
modelling  the  menu  structure  of  the  prototype.  Symbols  on  the  CFG  represent  buttons  on  the 
proposed  menu  interface  and  can  be  linked  to  what  will  happen  during  execution  of  the  system 
modules.  A  realistic  demonstration  of  the  interface  can  be  accomplished  by  using  CFGs,  tied 
to  a  RDBMS,  to  query  a  preliminary  database  and  show  the  user  the  results  of  the  actions  taken 
by  pushing  menu  buttons.  Data  Flow  Diagrams,  and  Entity-Relationship  Diagrams  (ERDs) 
remain  available  for  discussion  with  the  user  about  how  the  system  will  carry  out  these 
functions,  if  necessary. 

User  comments  on  the  first  prototype  are  then  included  in  subsequent  prototype  iterations, 
step  six  on  the  diagram  (figure  2).  Recursive  actions  may  occur  throughout  the  model  up  to  this 
point.  Once  the  final  prototype  has  been  accepted  by  the  user  (step  7)  a  preliminary  system 
design  document  is  generated  using  the  DFDs,  ERDs,  and  CFGs  developed  in  the  prototyping 
phase.  This  is  followed  by  fine  tuning,  implementation,  testing,  and  operation  and  maintenance 
(steps  9  and  10). 

Connell  and  Shafer’s  ideas  are  especially  well  suited  to  database  design  projects  because 
of  the  linkage  of  CASE  and  demonstration  tools  to  the  RDBMS.  Many  individual  user  views 
of  the  database  could  be  easily  assimilated  into  a  global  view  for  further  design  activities  using 
Connell  and  Shafer’s  methodology.  The  application  of  this  procedure  to  the  challenge  of 
developing  global  data  sets  for  multi-national  users  is  particularly  promising.  The  importance 
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of  modelling  the  user  interface  in  Connell  and  Shafer’s  rapid  prototyping  approach  also  makes 
it  an  ideal  candidate  for  use  in  system  application  development  projects,  including  CIS 
applications.  Some  modification  of  the  interaction  with  the  user  during  demonstration  of  the 
prototype  would  be  required  due  to  the  nature  of  the  spatial  data  and  output  characteristics  of 
GISs.  Any  small  project  where  time  is  a  critical  factor  and  where  initial  requirements  are  not 
well  defined  are  also  good  candidates  for  rapid  prototyping. 

One  important  component  of  prototyping  that  Connell  and  Shafer  stress  is  the 
communication  element.  Users  must  have  a  clear  understanding  regarding  their  responsibilities 
to  be  productive  members  of  the  prototyping  team.  These  responsibilities  must  be  spelled  out 
in  a  project  plan  before  work  is  started.  If  the  project  plan  is  made  available  to  all  prospective 
users,  many  misunderstandings  can  be  avoided  and  the  disadvantages  to  prototyping  will  be 
lessened. 

The  use  of  prototyping  is  currently  in  a  transition  within  the  software  engineering  field. 
Although  most  traditional  uses  of  prototyping  include  activities  focused  upon  software 
development  and  implementation,  many  software  engineers  are  moving  toward  the  use  of 
prototyping  throughout  the  design  process,  especially  in  the  critical  area  of  requirements 
analysis. 


Linking  CIS  Design  and  Software  Engineering 
Marble  (1983)  was  the  first  to  call  for  "drawing  upon  some  of  the  concepts  and  tools 
developed  ...  in  the  field  of  software  engineering"  to  advance  GIS  design.  However  Marble 
and  Wilcox  (1991)  continued  this  initial  work  by  arguing  that  several  crucial  differences 
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"separated  GIS  design  activities  from  those  in  software  engineering."  The  focus  of  software 
engineering  techniques  on  the  creation  of  working  code  was  one  critical  factor.  The  GIS  design 
process  is  primarily  intended  to  aid  in  the  selection  between  "competing  and  complex  spatial  data 
handling  systems"  (Marble  and  Wilcox,  1991).  However,  recent  suggestions  in  the  software 
engineering  literature  to  use  prototyping  primarily  as  a  requirements  analysis  tool  and  to  later 
focus  on  implementation  activities  may  overcome  some  of  the  obstacles  to  its  use  as  noted  by 
Marble  and  Wilcox. 

One  example  of  a  GIS  design  project  where  prototyping  was  used  can  be  found  in  the 
Defense  Mapping  Agency’s  GIS  database  development  project,  the  Digital  Chart  of  the  World. 
An  examination  of  this  case  may  help  us  clarify  the  role  of  prototyping  in  GIS  design. 
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CHAPTER  3 


AN  OVERVIEW  OF  THE  DIGITAL  CHART  OF  THE  WORLD  PROJECT 

Within  the  Department  of  Defense  (DoD),  there  is  an  increasing  base  of  GIS  users  who 
have  been  eagerly  adopting  GIS-related  technology  on  an  ad  hoc  basis.  Many  of  these  users 
have  focused  upon  their  own  specific  circumstances  in  order  to  contract  directly  with  vendors 
for  geographic  information  systems  geared  toward  their  own  supposedly  unique  situations.  The 
Defense  Mapping  Agency  (DMA),  the  entity  within  the  DoD  responsible  for  producing, 
maintaining,  storing,  and  distributing  maps,  charts,  geodetic  data,  and  related  products  for  the 
department,  was  often  omitted  from  these  processes.  Recently,  over  one  hundred  contracts  for 
digital  versions  of  traditional  paper  maps  were  let  in  the  Department  of  Defense  without  DMA 
oversight  (Digital  Products  Study,  Summary  Report,  1991)  This  omission  was  contrary  to  DoD 
directives  but  can  be  traced  to  the  fact  that  DMA  did  not  produce  topologically  structured  data 
for  use  in  GISs. 

This  situation  has  led  to  a  proliferation  of  GISs  in  a  wide  variety  of  organizations,  with 
each  often  requiring  data  sets  in  unique  formats  in  order  to  operate.  The  GIS  acquisition  process 
has  mirrored  the  development  of  the  now  prevalent  "smart"  weapons  systems  (cruise  missiles, 
guided  munitions,  etc.)  in  the  1970s  and  1980s  many  of  which  rely  upon  digital  geographic  data 
(non-topologically  structured  raster  and  vector  data)  for  navigation  and  targeting  capabilities. 
During  this  period,  databases  for  very  specific  digital  products  were  developed  and  acquired. 
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at  great  expense  in  time  and  money,  for  each  weapon  system  requiring  digital  data.  The  result 
was  a  cumbersome  structure  for  acquiring  data  in  various  digital  forms  wherein  the  producer 
often  transformed  one  data  set  into  another  format  for  use  in  another  system. 

The  Defense  Mapping  Agency,  in  an  effort  to  forestall  such  a  fragmented  approach  to 
the  development  of  GIS  in  DoD,  has  undertaken  an  effort  to  develop  a  standard  for  digital  vector 
data  and  a  sample  digital  database  through  a  development  project  called  the  Digital  Chart  of  the 
World  (DCW).  Their  recognition  of  the  importance  of  GIS  technology  to  their  users,  and  their 
entry  into  the  world  of  GIS  by  explicitly  supporting  the  users  with  data,  is  a  significant  milestone 
in  the  advancement  of  GIS  within  the  Federal  establishment.  The  well  defined  organizational 
structure  of  DoD,  the  public  availability  of  the  DCW,  and  the  use  of  an  innovative  design 
process  offer  a  unique  opportunity  to  study  the  role  of  prototyping  in  the  development  of  the 
database  component  of  a  GIS,  the  interactions  between  DMA  and  its  customers  in  the 
department,  and  DMA’s  first  efforts  to  support  users  of  GIS. 

It  is  important  to  note  that  this  study  relates  to  the  development  of  a  digital  product  based 
upon  a  traditional  cartographic  map  database  and  does  not  deal  with  the  implementation  of  a  new 
technology.  Rather,  it  deals  with  an  attempt  by  an  organization  to  involve  users  in  its  effort  to 
begin  production  of  topologically  structured  data  sets.  Before  we  begin  to  look  at  the  specifics 
of  the  DCW  development  process,  we  will  first  present  some  background  information  pertaining 
to  DCW,  then  attempt  to  obtain  a  better  understanding  of  how  DMA  functions  in  order  to  be 
better  able  to  understand  the  DCW  case. 
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The  DCW  Project 


The  DCW  began  in  October  1989  as  a  research  and  development  project  with  two 
objectives.  Since  DoD  units  were  increasingly  using  GISs,  the  first  goal  was  to  develop  a  "suite 
of  standards"  for  the  collection,  formatting,  and  exchange  of  topologically  structured  digital 
vector  data  (Statement  of  Work  (SOW),  1988).  The  "suite  of  standards"  subsequently  became 
known  as  the  Vector  Product  Standards  (VPS)  and  was  primarily  intended  to  allow  DMA’s 
customers  to  use  common  data,  whether  it  was  acquired  through  DMA  or  a  contractor.  The 
second  goal  was  to  build  a  sample  global  database  at  the  1:1,000,000  scale  according  to  these 
standards.^  Originally,  these  two  goals  shared  equal  priority  (SOW,  1988);  later  documentation 
stated  that  this  DCW  research  and  development  project  "has  as  its  primary  goal  the  development 
of  Vector  Product  Standards  (VPS)  for  the  provision  of  digital  geographic  information  to 
Department  of  Defense  (DoD)  and  Intelligence  Community  activities"  (Danko,  1990).  The 
changing  priorities  with  respect  to  these  two  goals  had  a  significant  impact  on  the  progress  of 
the  development  effort  and  will  be  examined  in  later  sections  of  this  paper. 

The  VPS  standard  developed  as  part  of  the  DCW  project  is  designed  to  serve  as  a  basis 
for  all  future  GIS  products  produced  in  the  Department  of  Defense  (Lang,  1992).  All  DoD 
users  of  vector-based  GIS  products  will  be  required  to  conform  to  the  VPS.  A  variety  of  digital 
data  standards  already  exist  in  DoD  but  are  focused  on  the  exchange  of  data  between 
cartographic  data  producers  such  as  DMA,  the  United  States  Geological  Survey  (USGS),  the 
National  Oceanic  and  Atmospheric  Administration  (NOAA),  and  various  foreign  producers. 


^  Bickmore  (1988),  in  Building  Databases  for  Global  Science, 
suggested  the  creation  of  a  digital  base  map  of  the  world  showing 
topographic  relief  at  the  1:1,000,000  scale. 
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DMA’s  "quest  [was]  to  establish  standards  that  will  be  embraced  by  the  community  of 
customers"  and  will  be  used  by  its  customers  for  "the  collection,  formatting,  and  exchange  of 
digital  geographic  information"  (Danko,  1992).  The  standards  were  required  to  be  user  oriented 
and  to  work  in  a  variety  of  computing  environments  with  a  variety  of  vector  data  (SOW,  1988). 
In  other  words,  the  standards  were  not  to  be  tied  to  any  one  product  but  should  allow 
specifications  for  new  products  to  use  the  standards  in  order  to  generate  vector  data  in  a  standard 
format.  The  standard  for  the  data  format,  known  as  the  Vector  Product  Format  (VPF),  formed 
the  heart  of  the  VPS  "suite  of  standards"  and  was  explicitly  targeted  towards  users  who 
individually  contracted  for  the  production  of  data  sets  (see  Appendix  3  for  a  summary  of  VPF). 

The  DCW  database  produced  during  this  development  project  is  a  medium-scale  digital 
vector  database  obtained  by  digitizing  the  Operational  Navigation  Charts  (ONCs).  The  ONCs 
are  the  largest  scale  product  in  the  DMA  inventory  with  world-wide  coverage  (except  Antarctica) 
and  are  cooperatively  produced  by  many  countries.  Since  ONCs  do  not  include  all  of  the 
world’s  landmass,  six  Jet  Navigation  Charts  (1:2,(X)0,000  scale)  were  used  over  Antarctica  to 
provide  complete  coverage.  Several  factors  led  to  the  decision  to  use  ONCs  to  produce  a  global 
database  in  conjunction  with  the  development  of  the  Vector  Product  Standards.  The  first  was 
the  stated  need  by  DMA  to  provide  a  wealth  of  data  in  the  proposed  format  to  "attract  the  users 
and  promulgate  the  standards"  (Danko,  1990).  There  was  also  a  stated  need  "throughout  DMA 
and  the  entire  Mapping  and  Charting  community  for  a  global  database  at  a  small  scale"  (SOW, 
1988).  It  is  interesting  to  note  that  this  latter  need  statement  begins  by  identifying  DMA  as  one 
of  those  who  need  the  database  and  then  moves  to  the  normal  object  of  DMA’s  attention,  its 
customers  throughout  the  DoD. 
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The  Digital  Chart  of  the  World  database  provides  standard  topographic  information 
consistent  with  1:1,000,000  scale  map  products,  including  elevation  contours,  transportation 
routes  (roads,  railways,  canals,  etc.)  populated  places,  drainage,  coastlines  and  international 
boundaries  (Danko,  1992).  Some  information  is  missing  for  certain  features  on  the  base  map 
of  the  ONC  due  to  the  primary  intended  use  of  the  charts  (aerial  navigation).  In  these  cases, 
data  were  added  to  the  DCW  database  from  other  sources.  For  example,  roads  are  not 
connected  through  cities  on  ONCs  because  the  intended  use  for  the  product  called  only  for  city 
outlines  which  might  show  up  on  radar  return  displays.  Roads  were  connected  through  city 
outlines  in  the  DCW  database  using  alternative  sources.  A  complete  list  of  thematic  layers 
included  in  the  DCW  data  base  follows: 


Table  1 

DCW  Thematic  Layers 
(DCW  Interim  Product  Specification,  1991) 


Aeronautical  Data 
Cultural  Landmarks 
Data  Quality 
Drainage 
Hypsography 
Land  Cover 
Ocean  Features 
Physiography 


Political/Oceans 
Populated  Places 
Railroad 
Road 

Transportation  Structure 

Utilities 

Vegetation 

ONC  Index 


A  digital  gazetteer  also  is  included  which  allows  one  to  display  place  names  on  the  database 
display  (DCW  Interim  Product  Specification,  1991). 

Four  countries,  Australia,  Canada,  New  Zealand,  and  the  United  Kingdom,  fully 
participated  in  the  project  as  the  cooperative  producers  of  the  ONC  series  as  well  as  potential 
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users  of  the  topologically  structured  global  database  (Danko,  1992).  The  map  and  chart 
producing  agencies  from  these  countries  acted  as  DMA  customers  in  this  project  and  augmented 
the  base  of  U.S.  DoD  customers  involved  in  reviews  of  the  prototyping  effort.  Though  the 
foreign  users  provided  half  of  the  initial  review  group,  this  study  of  the  organization  and 
interaction  of  this  customer  base  during  the  DCW  project  we  will  only  focus  upon  the  U.S. 
users.  The  U.S.  users  were  the  only  personnel  accessible  for  interviews. 

Organizational  Context  of  Department  of  Defense  Units  Involved  in  Mapping 

Before  we  launch  the  case  study,  it  is  important  to  understand  the  changing  world  in 
which  DMA  is  operating  because  this  external  environment  affects  the  definition  and  satisfaction 
of  requirements  levied  upon  DMA.  Traditionally,  DMA  has  been  a  giant  map  factory,  spitting 
out  massive  amounts  of  paper  maps  and  charts,  geodetic  data,  and  digital  data  intended  for 
specific  purposes.  The  agency  responds  to  input  from  its  "customers,"  that  is  the  combat 
commanders  from  all  branches  of  the  military  and  the  services  individually  (in  their  role  as 
trainers  and  weapon  system  developers).  Communication  in  the  military  system  flows  up  and 
down  the  "chain  of  command"  in  a  formal  fashion  and  is  sometimes  fragmented  and  incomplete 
and  is  supplemented  by  informal  information  which  is  often  passed  horizontally  between  units 
of  different  commands.  Communication  between  DMA  and  its  customers  is  no  different.  A 
large,  well  understood  bureaucratic  system  has  evolved  over  time  to  carry  out  the  military 
mapping  mission. 

To  aid  our  understanding  of  the  issues  involved  in  the  development  of  the  DCW  one  must 
know  how  the  Department  of  Defense  is  structured  and  how  the  various  entities  within  the 
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department  interact  with  DMA.  After  delineating  the  structure  of  the  department  and  the  role 
of  the  commands,  services,  and  service  laboratories  in  mapping  affairs,  we  will  examine  the  way 
in  which  DMA  operates. 

Structure  of  the  Department  of  Defense 

The  Department  of  Defense  is  a  large  organization  with  very  well-defined  roles  for  many 
of  its  subordinate  elements.  The  Secretary  of  Defense  sits  atop  a  structure  of  under  secretaries 
and  assistant  secretaries  responsible  for  various  aspects  of  defense  policy.  The  Joint  Chiefs  of 
Staff  are  the  secretary’s  military  advisors.  Together,  the  Chairman,  Vice  Chairman,  and  the 
Chiefs  of  the  four  military  services  are  responsible  for  setting  strategic  direction  and  broad 
military  planning  for  both  strategic  and  contingency  situations  (Joint  Staff  Officers  Guide,  1991). 
Figure  3  illustrates  the  organizational  structure  of  the  department  and  can  be  referred  to 
throughout  the  following  discussion. 

In  addition  to  their  responsibilities  as  Joint  Chiefs  of  Staff,  the  four  Chiefs  of  the  services 
“wear  another  hat"  while  they  supervise  their  respective  services.  The  services  are  responsible 
for  organizing,  training  and  equipping  forces  so  that  they  are  capable  of  carrying  out  the 
assigned  missions  of  the  Unified  and  Specified  (U&S)  Commands.  The  U&S  Commands  are 
the  "warfighters,"  responsible  for  carrying  out  national  security  objectives  throughout  the  world 
by  assuming  operational  control  over  the  services’  units  during  war.  Each  service  and  command 
has  a  headquarters  component  that  exercises  control  over  all  of  its  functions,  including  the 
definition  of  mapping  requirements. 

Mapping  requirements  may  include  requests  for  new  products  required  for  development 
of  weapon  systems  or  the  definition  of  area  coverage  requirements  for  certain  products  for 
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Department  of  Defense  (DoD)  Organization 


Source:  Joint  Staff 

Officer's  Guide,  1991 


Figure  3 
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operational  purposes.  Each  service  has  a  laboratory  responsible  for  the  planning  and 
development  of  new  mapping  technology  (in  the  Navy  and  Army’s  cases  the  laboratories  focus 
solely  on  mapping  technology  while  the  Air  Force  laboratory  that  accomplishes  this  function  has 
a  broader  mission).  The  labs  are  the  primary  submitters  of  new  product  requirements  which 
must  be  forwarded  to  DMA  through  the  service  headquarters. 

Unified  commands  are  joint-service  commands  (two  or  more  military  services) 
responsible  for  certain  areas  of  the  world  or  certain  functions.  The  Unified  Commands 
responsible  for  specific  areas  in  the  world  are:  U.S.  Pacific  Command,  U.S.  Atlantic  Command, 
U.S.  European  Command,  U.S.  Southern  Command  (responsible  for  Latin  America),  and  U.S. 
Central  Command  (responsible  for  most  of  Africa  and  the  Middle  East,  including  Asia  Minor). 
Unified  Commands  responsible  for  carrying  out  specific  functions  are:  U.S.  Transportation 
Command,  U.S.  Special  Operations  Command,  and  U.S.  Space  Command.  Each  of  the  Unified 
Commands  consists  of  a  small  headquarters  staff  during  peacetime.  During  war,  Unified 
Commands  take  control  of  operational  units  provided  by  the  services  to  carry  out  operational  war 
plans.  Specified  Commands  include  Strategic  Air  Command  (Air  Force)  and  Forces  Command 
(Army);  each  is  responsible  for  broad  continuing  missions  generic  to  each  service  (nuclear 
deterrence  in  the  case  of  the  Air  Force).  Specified  Commands  have  large  headquarters  and 
control  many  units  in  the  course  of  their  continuing,  day-to-day  missions  (The  Joint  Staff 
Officers  Guide,  1991).  The  commands  submit  the  largest  block  of  requirements  for  area 
coverages  due  to  their  global  operational  commitments. 
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Defense  Agencies  are  mostly  civilian  organizations,  performing  specific  non-combat 
functions  within  the  department  which  also  require  them  to  submit  mapping  requirements.  They 
include: 


Defense  Advanced  Research  Projects  Agency 

Defense  Communications  Agency 

Defense  Contract  Audit  Agency 

Defense  Intelligence  Agency 

Defense  Investigative  Service 

Defense  Legal  Services  Agency 

Defense  Logistics  Agency 

Defense  Mapping  Agency 

Defense  Nuclear  Agency 

Defense  Security  Assistance  Agency 

National  Security  Agency 

On-Site  Inspection  Agency 

Strategic  Defense  Initiative  Organization 


Each  agency  interacts  with  the  Joint  Staff,  Unified  and  Specified  commands  and  the  military 
services  in  differing  ways.  For  instance,  the  Defense  Intelligence  Agency  serves  as  the  Joint 
Chiefs’  staff  intelligence  element  in  addition  to  its  duty  to  provide  intelligence  support 
information  to  the  commands  and  services.  The  Defense  Mapping  Agency  supports  the  entire 
department  by  responding  to  requirements  levied  by  the  commands,  services,  defense  agencies, 
and  others. 

Interaction  between  Commands,  Services,  and  DMA 

It  is  important  to  remember  that  the  military  services  are  primarily  responsible  for 
submitting  new  mapping  requirements  for  emerging  weapon  systems  and  tactics  to  DMA.  The 
services  use  their  service  labs  to  refine  their  requirements,  often  taking  new  products  from  DMA 
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and  letting  the  labs  run  the  tests  and  evaluations.  In  addition,  the  laboratories  submit 
requirements  for  developing  systems  through  the  service  headquarters  to  DMA. 

Combat  commanders  in  the  Unified  and  Specified  commands  submit  requirements  to 
DMA  for  area  coverage  of  the  standard  products  DMA  produces.  Defense  Agencies  and  other 
government  entities  also  submit  requirements  to  DMA  but  traditionally  receive  less  attention 
since  the  combat  commands  and  the  services  receive  the  lion’s  share  of  support  due  to  the  size 
of  their  requirements  and  the  magnitude  of  the  systems  they  employ  (see  Figure  4  for  a 
representation  of  the  operational  relationships  between  DMA  and  its  customers). 

All  of  the  requirements  submitted  to  DMA  are  prioritized  according  to  a  scheme 
implemented  by  the  Joint  Chiefs  of  Staff.  The  exact  nature  of  the  decision  criteria  used  to 
determine  who  gets  top  priority  support  remains  classified  but  can  be  said  to  favor  operational 
commitments  of  deployed  military  forces.  The  system  is  far  from  static  and  lower  priorities 
frequently  move  up  the  ladder,  including  those  of  the  smaller  units  and  defense  agencies.  This 
movement  may  be  at  the  direction  of  the  Joint  Staff  or  internally  programmed  by  DMA. 

Within  this  organizational  context  of  mapping  affairs,  we  will  now  look  at  the  recent 
history  of  the  new  product  planning  and  area  requirements  processes.  Developments  in  these 
areas  have  greatly  influenced  the  way  in  which  DMA  sees  its  own  responsibilities  and  its  role 
within  DoD. 


Defense  Mapping  Agency’s  Customer  Support 
In  the  dynamic  world  in  which  we  live,  DMA  must  constantly  work  to  be  responsive  to 
the  seemingly  ever  changing  needs  of  the  user  community.  New  product  planning  takes  place 
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Customer  Interaction  with 
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as  needed,  and  is  very  common  as  new  weapon  systems  are  developed  which  require  digital 
mapping  data.  Military  contingencies,  real-world  as  well  as  exercises,  often  throw  the  orderly 
structure  representing  DMA’s  best  efforts  to  plan  new  products  and  produce  according  to  area 
requirements  into  chaos. 

As  a  relatively  small  agency,  DMA  often  suffers  neglect  from  the  designers  and 
developers  of  weapon  systems.  Designers  often  fail  to  express  requirements  for  new  mapping 
or  digital  products,  or  submit  them  to  DMA  very  late,  in  the  development  cycle.  DMA  can  not 
easily  uncover  and  track  every  weapon  system  development  project  in  the  department  and  must 
rely  on  the  developer  to  determine  mapping  requirements.  Military  commanders  also  have  had 
an  historical  tendency  to  keep  DMA  in  the  dark  regarding  certain  requirements  because  of  the 
need  for  security.  Recent  steps  have  helped  to  correct  both  of  these  situations  but  the  agency 
still  faces  an  uphill  battle  in  making  its  case  known. 

The  agency’s  efforts  to  win  these  battles  has  led  to  a  new  role  for  DMA,  a  role  which 
was  internally  generated  as  a  form  of  survival  strategy.  DMA  now  tries  very  hard  to  anticipate 
user  needs  by  remaining  in  close  contact  with  new  weapon  system  developers  and  combat 
commanders.  Because  of  the  size  and  organization  of  the  Department  of  Defense  and  the 
communication  system  in  place,  this  is  difficult  at  best.  Other  efforts  to  win  this  battle,  such 
as  the  recent  attempt  to  adopt  digital  mapping  data  standards  to  force  developers  to  utilize 
existing  DMA  products,  lacked  any  real  direction  for  a  number  of  years.  The  standards  effort 
also  suffered  from  a  lack  of  real  enforcement  options  and  consequent  neglect.  All  of  these 
things  together  combined  to  spur  DMA  to  adopt  a  new  attitude  and  direction  for  its  activities. 
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DMA’s  Traditional  Role  Versus  Recent  Needs  to  be  More  Proactive 


In  1983,  the  United  States  undertook  a  military  operation  to  invade  the  island  of  Grenada 
and  rescue  American  college  students  from  the  perceived  dangers  of  the  political  and  social 
upheaval  associated  with  a  coup  d’etat.  This  engagement  marked  the  start  of  the  change  in 
DMA’s  role  in  the  Department  of  Defense.  Leading  up  to  the  invasion,  DMA  served  as  a  giant 
map  factory,  churning  out  thousands  of  maps  a  year  at  an  incredibly  slow  pace.  Maps  and 
digital  data  often  took  18  months  or  more  to  produce  while  changing  to  crisis  production  often 
meant  a  complete  halt  to  all  extraneous  production  in  favor  of  products  supporting  contingency 
operations.  The  planners  of  Operation  URGENT  FURY,  as  the  Grenada  invasion  was  known, 
decided  to  keep  DMA  out  of  the  loop  in  the  planning  process  and  rely  on  the  Army’s  minimal 
topographic  assets  for  maps.  This  decision  was  based  on  the  perception  that  DMA  could  not 
provide  the  maps  in  the  required  time  frame  without  a  massive  production  effort.  Such  an  effort 
would  have  jeopardized  security  because  of  the  vast  numbers  of  people  at  DMA  who  would  have 
had  to  have  knowledge  of  the  impending  operation.  Only  when  the  operation  was  imminent  did 
a  request  come  to  DMA  for  the  standard  set  of  combat  maps  and  charts.  The  result  was  the  now 
famous  "British  tourist  map"  that  served  as  the  Army’s  base  map  and  was  used  by  the  invading 
forces  until  DMA’s  standard  products  arrived  well  after  the  fighting  began. 

This  "tourist  map"  was  actually  a  very  good  map  produced  by  the  United  Kingdom’s 
Ordnance  Survey.  However,  Army  mappers  overlaid  an  arbitrary.  Universal  Transverse 
Mercator  (UTM)  -like,  grid  on  the  map  to  accommodate  military  operations  such  as  artillery 
support.  This  map  worked  well  until  personnel  confused  the  arbitrary  grid  with  the  UTM  grid 
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for  the  region.  Matters  were  not  helped  when  DMA  rushed  standard  military  maps  to  the  area 
(with  genuine  UTM  grids). 

The  resulting  confusion,  "friendly  fire"  incidents,  and  the  like  led  to  efforts  to  make 
DMA  more  responsive  to  real-world  contingencies  and  to  get  the  military  commands  to  loosen 
operational  security  enough  to  alert  DMA  far  enough  in  advance  to  allow  the  production  of 
standard  maps,  charts,  and  digital  data.  Over  the  years,  the  processes  for  communicating  the 
users’  new  product  and  area  coverage  requirements  continued  and  slowly  improved. 

Throughout  this  metamorphosis,  DMA  strived  to  condense  production  time  through 
internal  measures  and  to  reach  out  to  the  commands  with  proposals  to  improve  communication 
and  trust.  However,  other  circumstances  such  as  the  need  to  adjust  operating  budgets  throughout 
the  government  led  to  situations  which  impacted  DMA’s  ability  to  satisfy  its  users. 

Impact  of  Budget  Cuts  on  New  Product  Planning 

The  usual  approach  to  new  product  development  at  DMA  has  been  via  a  top-down 
specification  model.  This  approach  requires  a  great  deal  of  effort  at  the  front  end  by  both  the 
developers  and  the  users.  Once  specifications  are  written,  the  developer  can  proceed  to  produce 
the  final  product  according  to  the  blueprint.  It  is  possible  that  the  first  users’  test  of  the  new 
product  may  be  very  near  to  final  delivery,  or  at  least  not  until  after  a  great  deal  of  time  and 
money  has  been  spent  implementing  the  design.  This  approach  is  not  unique  to  the  Defense 
Mapping  Agency;  many  Army,  Air  Force,  and  Navy  laboratories  also  function  in  this  manner. 
As  a  result,  it  is  not  unusual  for  projects  to  require  long  lead  times,  sometimes  on  the  order  of 
a  decade  for  large  projects.  Under  this  procedure,  DMA  bore  the  costs  associated  with  new 
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product  development  unless  an  urgent,  unprogrammed  request  required  the  transfer  of  funds 
from  the  customer’s  development  account. 

Reduced  budgets  in  the  middle  1980s  forced  certain  decisions  regarding  the  way  in  which 
DMA  and  the  services  interacted  during  new  product  planning.  When  cruise  missiles  were 
developed  in  the  seventies,  the  developers  built  the  missiles  and  specified  the  data  needed  to 
make  them  work.  DMA  paid  for  the  development  of  products  such  as  Digital  Terrain  Elevation 
Data  and  Terrain  Contour  Matching  Matrices  used  by  the  missile  for  navigation  and  targeting. 
As  the  eighties  wore  on,  budgets  became  increasingly  smaller  while  technology  allowed  new  and 
more  advanced  weapon  systems  to  be  built.  To  counter  the  Soviet  Union’s  continued 
deployment  of  more  and  more  advanced  weapons,  the  United  States  military  responded  by 
developing  new  requirements  for  weapon  systems  and  the  associated  mapping  data  needed  to 
make  them  work.  Eventually  this  led  to  a  decision  in  a  DoD  document  pertaining  to  DMA’s 
budget  known  as  PDM  85  (or  Program  Decision  Memorandum,  1985).  PDM  85  stated  that 
services  specifying  the  need  for  new  mapping  products  for  developing  weapon  systems  must  pay 
for  the  products  (other  conditions  also  applied  such  as  cost  thresholds,  etc.,  but  they  are  not 
relevant  to  this  discussion). 

It  should  not  be  surprising  that  under  these  conditions  a  number  of  requirements  for  new 
products  suddenly  disappeared.  In  addition,  it  has  been  asserted  that  other  requirements  for 
some  digital  data  sets  never  materialized  since  no  single  service  desired  to  pay  all  the  costs  of 
a  product  that  every  other  service  within  the  department  could  use.  Weapon  system  developers 
decided  to  make  do  with  transformations  of  standard  DMA  products  or  circumvented  the  system 
by  directly  contracting  with  civilian  firms  for  the  required  products.  In  fact,  DMA  was  put  into 
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the  awkward  position  of  trying  to  negotiate  between  elements  of  the  user  community  in  these 
matters.  To  this  day,  PDM  85  has  not  been  enforced. 

One  consequence  of  the  actions  brought  about  by  PDM  85  was  that  a  frame  of  mind 
developed  among  many  users  who  began  to  go  to  commercial  vendors  to  acquire  digital  data. 
Contracting  with  vendors  was  perceived  to  be  faster  and  easier  than  working  with  DMA.  This 
led  to  a  proliferation  of  data  in  a  wide  variety  of  formats  and  media  and  to  interoperability 
problems  between  military  commands. 

To  alleviate  interoperability  problems,  DMA  decided  to  formalize  what  had  been  "de 
facto  standards"  associated  with  the  success  of  certain  products.  This  type  of  "standard"  product 
was  only  considered  a  standard  because  so  many  systems  used  the  data  and  because  there  was 
a  vast  amount  of  data  available.  Digital  Terrain  Elevation  Data  (DTED),  which  was  used  by 
more  than  100  systems  (Digital  Products  Study,  Summary  Report,  1991)  is  a  prime  example  of 
one  of  these  "standard"  products.  The  former  "de  facto  standards"  were  processed  by  DMA 
through  the  Department  of  Defense  office  responsible  for  military  specifications  and  standards 
and  were  formally  converted  to  Military  Standards  (MILSTD).  Weapon  system  developers  were 
then  required  to  use  DMA  data  for  specific  applications;  Digital  Terrain  Elevation  Data  became 
the  MILSTD  for  all  systems  requiring  digital  elevation  data.  A  standard  for  topologically 
structured  data  did  not  exist  because  DMA  did  not  directly  provide  GIS  users  with  much  useable 
data  in  this  area  (although  DTED  is  often  used  in  GISs). 
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Confusion  Among  DoD  Users  of  CIS 


DMA’s  traditional  focus  on  supporting  the  commands  and  services  remained  its  primary 
goal  during  efforts  to  use  a  proactive  approach  to  head  off  surprises  in  the  new  product  and  area 
coverage  requirements  processes  of  its  biggest  customers.  Attempts  to  implement  standards  for 
the  use  of  products,  coupled  with  perceptions  generated  during  an  era  of  increasingly  tighter 
budgets,  led  to  a  great  deal  of  confusion  when  DoD  elements  began  to  implement  Geographic 
Information  Systems. 

Intelligence  agencies,  which  perform  varied  analyses  of  world  events,  were  well  suited 
for  the  adoption  of  GIS  technology  and  were  the  first  users  of  GISs  within  DOD.  Because  DMA 
lacked  topologically  structured  data  sets  and  paid  little  attention  to  the  intelligence  agencies’ 
requirements  in  day-to-day  operations,  these  first  GIS  users  carried  out  their  activities 
unilaterally.  In  addition,  since  their  GIS  activities  were  often  conducted  in  highly  classified 
programs,  the  intelligence  agencies  did  not  try  very  hard  to  move  DMA  into  the  GIS  arena  due 
to  security  concerns. 

As  more  and  more  elements  in  DoD  added  GIS  capabilities,  including  the  commands  and 
services,  DMA  tried  to  enforce  digital  data  standards  for  its  existing  products,  which  failed  to 
meet  the  users’  needs.  It  soon  became  apparent  that  the  agency  needed  to  support  GIS  users 
with  standards  and  topologically  structured  data.  The  Digital  Chart  of  the  World  project  was 
undertaken  for  these  reasons. 
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CHAPTER  4 


THE  DIGITAL  CHART  OF  THE  WORLD  CASE 


The  Defense  Mapping  Agency  recognized  a  need  to  provide  a  topologically  structured 
data  set  to  the  DoD  community  to  "support  the  selective  display,  geographic,  modelling, 
analytical,  and  predictive  capabilities"  (Danko,  1992)  being  introduced  by  the  adoption  of  GIS 
technology.  They  believed  that  to  encourage  use  of  this  database  there  must  be  a  wealth  of  data 
developed  according  to  a  standard  format.  A  global  database  like  the  DCW  would  be  well  suited 
for  users  who  have  applications  in  command,  control,  communications,  and  intelligence,  mission 
planning,  and  global  monitoring.  In  addition,  DMA  has  stated  that  the  international  mapping 
community  has  long  been  interested  in  building  a  global  database  such  as  the  DCW  (Danko, 
1992;  Bickmore,  1988). 

While  these  are  worthy  reasons  for  undertaking  a  project  such  as  the  DCW,  it  is  clear 
that  the  original  requirement  for  these  standards  and  data  sets  originated  from,  and  was  defended 
from  within,  DMA.  We  will  see  that  many  users  are  in  fact  concerned  about  DMA’s  efforts  to 
produce  a  product  based  upon  needs  sensed  by  the  agency  rather  than  expressed  by  the  people 
DMA  serves.  In  the  following  sections  we  will  deal  with  these  issues,  but  first  we  will  look  at 
the  way  in  which  DMA  executed  the  project,  given  that  they  decided  a  need  existed,  and  the 
response  to  their  use  of  prototyping  by  the  people  involved  in  every  aspect  of  the  project. 
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Implementation  of  Prototyping 


It  is  difficult  to  precisely  state  why  DMA  attempted  to  use  prototyping  in  the  DCW 
project.  Prototyping  in  this  case  was  probably  intended  to  be  used  as  a  requirements  analysis 
tool,  in  accord  with  recommendations  in  the  software  engineering  literature.  However,  the 
beginning  phases  of  the  DCW  project  violated  key  premises  of  prototyping  as  a  requirements 
analysis  tool.  In  addition,  it  is  important  to  note  that  DMA  often  uses  the  terms  "prototyping" 
and  "rapid  prototyping"  interchangeably  throughout  its  documentation  of  the  DCW  project  (see 
the  Statement  of  Work  (1988)  and  subsequent  articles  by  Danko  (1990  and  1992)  for 
illustration).  In  fact,  DMA’s  use  of  the  term  "rapid  prototyping"  has  little  in  common  with 
Connell  and  Shafer’s  methodology  and  is  probably  an  adequate  description  only  when  one 
considers  the  length  of  the  development  effort  and  the  impact  the  DMA-imposed  completion  date 
had  on  the  prototyping  process. 

The  Statement  of  Work  issued  by  DMA  to  interested  commercial  contractors  clearly  laid 
out  the  reasons  for  the  development  of  the  DCW  and  the  way  in  which  it  was  to  be  ac¬ 
complished.  Prototype  development  was  to  be  used  to  "aid  in  the  development  of  standards  and 
to  insure  completeness  in  compatibility,  information  content,  and  overall  design"  (SOW,  1988). 
The  need  to  determine  users’  requirements  for  the  product  or  the  standards  were  not  mentioned 
in  this  section;  instead  it  states  "[tjhe  prototypes  will  be  distributed  by  (sic)  DMA  users  for  test 
and  evaluation.  The  contractor  shall  use  the  results  from  this  and  other  prototype  data  interac¬ 
tions  to  improve  design"  (SOW,  1988).  This  statement  implies  a  rather  mechanical  process 
aimed  at  implementation  activities.  These  initial  statements  are  subsequently  contradicted  by 
assertions  that  "iterative"  prototyping  was  used  "to  ensure  that  the  final  standards  are  user 
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oriented  and  meet  user  requirements"  (Danko,  1992).  The  latter  assertion  indicates  prototyping 
was  intended  as  a  requirements  analysis  tool,  but  because  the  former  was  expressed  in  the 
Statement  of  Work,  it  probably  more  accurately  reflects  DMA’s  original  thinking.  This 
discrepancy  is  noteworthy  because  it  is  the  first  of  many  indications  that  user  needs  were  not  a 
primary  concern  in  the  selection  of  the  development  strategy.  DMA’s  need  to  establish 
standards  and  support  them  with  data  was  likely  the  primary  driving  force  of  the  prototyping 
effort. 

One  needs  only  to  examine  the  stated  purpose  of  the  Project  Requirements  Review  (PRR) 
to  determine  whether  user  requirements  were  of  the  utmost  importance.  The  PRR  was  the  first 
meeting  between  DMA  and  the  contractor  and  was  held  in  the  middle  of  November,  1989  to 
assure  that  the  contractor  understood  all  the  details  of  the  project  requirements.  Presentations 
at  the  PRR  were  supposed  to  include  an  "[ijnitial  requirements  matrix  allocating  DCW  attributes 
and  characteristics  to  [a]  specific  prototype  version  or  revision"  (SOW,  1988),  indicating  a 
preconceived  notion  of  user  needs.  One  may  be  surprised  to  find  out  that  an  assessment  of  user 
needs  was  not  accomplished  before  this  meeting.  Instead,  a  User  Needs  Survey  was  circulated 
at  the  PRR  and  was  completed  by  only  seven  participants.  DMA  obviously  had  a  predetermined 
set  of  requirements  for  the  project  before  both  the  PRR  and  the  user  survey  were  accomplished. 

During  initial  research  at  DMA  headquarters,  the  author  was  told  that  the  contractor 
(ESRI)  had  insisted  upon  the  initial  user  survey  which  was  performed  at  the  PRR  in  order  to 
determine  what  the  real  requirements  were  for  the  DCW  standard  and  product.  One  DMA 
interviewee  stated  the  contractor  persisted  in  this  area  because  they  never  had  worked  on  a 
project  where  a  user  needs  survey  hadn’t  been  accomplished.  The  DMA  speaker  told  the  author 
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he  was  surprised  by  the  contractor’s  insistence  and  asserted  that  while  the  users  really  needed 
the  DCW,  "they  just  don’t  know  it  yet."  Variations  of  this  statement,  that  the  users  needed  the 
DCW  and  similar  data  along  with  digital  data  standards  oriented  toward  GIS  users  but  "just 
haven’t  expressed  a  requirement,"  were  repeated  throughout  the  interviews  conducted  at  DMA. 

DCW  Development  History 

Despite  the  untimeliness  and  limited  scope  of  the  assessment  of  user  needs,  the  design 
process  continued  and  was  refined  based  upon  input  from  representatives  of  the  user  community. 
The  development  of  the  standards  and  the  DCW  product  can  be  traced  through  the  construction 
of  four  prototypes,  each  of  which  was  issued  to  an  increasing  number  of  review  sites.  Each 
prototype  consisted  of  increasing  quantities  of  data  from  a  cross-section  of  DMA  products  (to 
ensure  the  standards  would  support  the  building  of  more  data  sets  at  different  scales  in  the 
future).  In  each  case,  users  were  generally  allowed  30  days,  or  less,  to  review  the  prototype 
before  a  design  review  meeting  was  conducted.  An  example  of  the  instructions  issued  to  the 
reviewers  is  contained  in  Appendix  4. 

The  DCW  first  prototype  was  a  small  data  set  which  used  standard  ARC/INFO  software 
to  display  a  mockup  of  the  DCW  and  was  delivered  to  about  40  reviewers.  The  second 
prototype  consisted  of  custom  software  and  data  from  several  cartographic  products  on  magnetic 
media.  This  allowed  more  users  to  evaluate  the  database  structure  as  well  as  the  software 
provided  which  enabled  the  user  to  view  the  data.  The  third  and  fourth  prototypes,  which  were 
on  Compact  Disks  -  Read  Only  Memory  (CD-ROM),  more  closely  resembled  the  intended  final 
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product  based  upon  Operational  Navigation  Charts  and  were  delivered  to  more  than  70 
reviewers. 

An  examination  of  the  time  line  associated  with  the  prototyping  activity  provides  an 
important  view  of  the  entire  development  process.  The  issue  dates  of  the  prototypes  together 
with  the  design  review  meeting  dates  are  listed  here  in  chronological  order.  These  are 
graphically  illustrated  in  Figure  5. 


Table  2 

Prototype  Issue  and  Review  Dates 


Event  Date 


Project  Requirements  Review 

October  1989 

and  User  Needs  Survey 

Prototype  1  Release  Date 

December  1989 

Design  Concept  Review 

January  1990 

Prototype  2  Release  Date 

April  1990 

Preliminary  Design  Review 

May  1990 

Prototype  3  Release  Date 

July  1990 

Project  Detailed  Design  Review 

August  1990 

Prototype  4  Release  Date 

December  1990 

Critical  Design  Review 

January  1990 

Interim  Progress  Review 

July  1990 

Further  details  about  the  development  process  will  be  highlighted  through  a  review  of  key 
documents  and  augmented  in  a  subsequent  section  by  an  analysis  of  the  participant’s  responses 
to  the  DCW  prototyping  effort. 

Execution  of  the  Prototyping  Process 

Several  documents  supplied  by  the  contractor  provided  insight  into  the  development  of 
the  DCW  database  and  associated  standards.  Each  design  review,  except  for  the  Project  Design 
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Review,  was  preceded  by  the  delivery  of  a  preliminary  data  package  of  information  to  the 
participants.  These  data  packages  included  information  about  the  next  meeting,  including  a 
detailed  agenda,  and  a  summary  of  the  last  meeting  and  the  activities  that  had  taken  place  during 
the  interceding  period.  Information  about  the  Project  Requirements  Review  was  included  in  the 
Pre-Design  Concept  Review  Data  Package.  Users  who  acted  as  reviewers  of  the  prototypes 
were  invited  to  each  meeting  along  with  developers,  DMA  personnel  and  their  international 
cooperative  partners,  and  subcontractors.  In  general,  the  Design  Concept,  Preliminary  Design, 
Project  Detailed  Design,  and  Critical  Design  Reviews  were  intended  to  discuss  the  contractor’s 
activities,  the  prototypes,  and  input  from  the  users  regarding  their  needs  and  evaluations. 

As  previously  stated,  the  PRR  was  the  first  meeting  between  DMA  and  the  contractor 
and  was  supposed  to  be  held  to  insure  that  the  contractor  understood  the  project  requirements. 
Although  it  is  very  clear  that  there  were  preconceived  notions  about  the  user  requirements  ESRI 
took  advantage  of  this  meeting  to  conduct  the  User  Needs  Survey  to  get  first-hand  knowledge 
of  requirements  directly  from  the  intended  users  (the  survey  is  attached  as  Appendix  5). 
Because  of  the  unfortunate  aspect  of  the  timing  of  these  activities,  the  first  prototype  was 
delivered  at  the  end  of  December  1989,  while  the  compiled  results  from  the  survey  were  not 
available  until  the  middle  of  January  (the  compiled  results  of  the  User  Needs  Survey  are  in 
Appendix  6).  Consequently,  the  only  direct  input  from  prospective  DCW  users  was  not  utilized 
in  building  the  first  prototype  (Pre-DCR  Data  Package,  1990). 

The  first  prototype  (40  copies)  was  delivered  during  the  end-of-the-year  holiday  period 
in  1989,  one  month  before  the  Design  Concept  Review  (DCR)  was  scheduled.  This  Prototype 
consisted  of  a  small  section  of  one  ONC,  and  a  small  patch  of  a  British  Admiralty  chart.  The 
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reviewers  were  provided  with  ARC/INFO  software  to  perform  the  evaluation  of  the  first 
prototype  (Danko,  1990).  It  is  important  to  note  that  reviewers  were  only  provided  with 
approximately  30  days  to  perform  their  functions  despite  problems  associated  with  the  holidays, 
mailing  time  related  to  delivery  of  the  prototype,  and  dispatch  of  their  comments  back  to  the 
contractor.  The  DCR,  held  at  the  end  of  January,  1991,  focused  on  the  contractor’s  conceptual 
design  of  the  DCW  and  utilized  user  input  and  the  results  from  the  User  Needs  Survey  to  begin 
discussion  and  development  of  the  second  prototype  (Pre-DCR  Data  Package,  1990). 

Prototype  2  was  produced  between  the  DCR  and  Preliminary  Design  Review  and  required 
12  weeks  for  its  creation.  This  prototype  was  issued  near  the  end  of  April,  1990  and  used 
original  code,  written  in  the  C  language,  to  implement  the  new  DCW  data  structure.  The  data 
utilized  consisted  of  the  two  previous  charts  and  also  included  two  National  Ocean  Service  charts 
and  a  section  of  a  1:50,000  topographic  map  (Danko,  1990).  Work  on  the  Vector  Product 
Standards  made  significant  strides;  the  conceptual  design  was  completed  and  included  database 
content  definition,  layer  definition,  and  CD-ROM  design.  This  prototype  was  delivered  to  more 
than  50  reviewers  and  provided  the  first  complete  view  of  the  product  and  its  contents  (Pre-PDR 
Data  Package,  1990).  The  PDR  was  held  at  the  end  of  May,  1990  and  was  used  to  discuss 
product  content,  the  vector  standards,  and  design  issues  such  as  tiling  and  indexing  of 
prototype  2. 

Prototype  3,  the  first  to  be  delivered  in  CD-ROM  form  according  to  the  new  standard 
format,  the  Vector  Product  Format,  was  issued  in  early  August,  1990.  This  prototype  consisted 
of  several  ONCs,  hydrographic  charts,  and  one  Jet  Navigation  Chart.  It  was  the  first  to  provide 
the  standards,  software,  and  data  in  one  product  to  the  evaluation  team  (Danko,  1990).  The  time 
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period  available  for  review  of  this  prototype  was  considerably  less  than  the  30  days  allowed  for 
both  of  the  previous  prototypes.  User  comments  and  production  design  were  presented  at  the 
Project  Detailed  Design  Review  held  at  the  end  of  August  1990  (Pre-PDDR  Data  Package, 
1990). 

The  fourth  and  last  prototype  was  delivered  at  the  end  of  December,  1990,  just  one 
month  before  the  Critical  Design  Review  (the  CDR  was  originally  scheduled  for  December  but 
was  delayed  until  the  middle  of  January,  1991).  Prototype  4  was  designed  to  test  both  the  data 
structures  and  the  production  process  using  four  ONCs  from  western  Europe  (Danko,  1990). 
The  purpose  of  the  CDR  was  to  provide  the  Government  assurance  that  the  contractor’s  design 
was  adequate  to  allow  database  production  to  begin.  Final  standards,  software,  and  production 
designs  were  presented.  During  this  period,  significant  upheaval  in  the  development  was  caused 
by  the  contractor’s  need  to  support  other  DMA  activities  during  Operation  DESERT 
SHIELD/STORM.  The  impact  of  this  support  will  be  discussed  in  more  detail  later  in  this 
paper.  The  Interim  Progress  Review  was  designed  to  provide  the  Government  with 

information  regarding  production  status  and  was  held  during  the  middle  of  July,  1991. 
Schedules  and  status  changes  were  discussed  and  a  prototype  for  Digital  Terrain  Data  was 
released.  This  latter  prototype  was  initiated  by  DMA  as  a  result  of  the  progress  demonstrated 
at  the  DCW  Critical  Design  Review  as  well  as  DMA’s  satisfaction  with  the  prototyping  process 
and  the  Vector  Product  Standards.  DMA  stated  that  the  DCW  "method  of  rapid  prototyping 
worked  very  well.  Engineering  ideas  were  quickly  tested;  the  designs  that  didn’t  work  were 
quickly  discovered  and  discarded"  (Danko,  1990). 
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Changing  Justification  for  Prototyping 

This  last  statement  reflects  how  DMA  was  more  interested  in  the  traditional  implementa¬ 
tion  activities  so  often  the  focus  of  software  engineering  methodologies.  It  is  another  indication 
that  satisfaction  of  the  users’  requirements  was  not  the  goal  of  prototyping  in  the  DCW 
development  project.  Unfortunately,  this  statement  further  clouds  our  effort  to  determine 
DMA’s  rationale  for  the  use  of  prototyping  in  the  DCW  development  project.  Further  insight 
into  the  prototyping  process  will  be  provided  by  an  examination  of  the  participant’s  views 
regarding  the  DCW  effort. 


Participants’  Responses  to  Prototyping 

For  purposes  of  this  study,  there  were  three  primary  participants  in  the  project;  the 
project  sponsor  (DMA),  the  developer  (ESRI),  and  potential  users  (military  commands,  services, 
and  DoD  agencies).  Participants  from  each  category  were  contacted  during  visits  to  three  sites. 
Their  roles  in  this  project  will  be  examined  in  the  following  section  along  with  their  reactions 
to  the  process  as  a  whole. 

Project  vSponsor 

Interviews  at  the  project  sponsor  level  were  held  with  six  individuals,  including  the 
contracting  officer  technical  representative  as  well  as  personnel  involved  in  the  program  through 
work  in  research  and  engineering  and  user  requirements  definition.  Some  consistent  themes  ran 
throughout  the  interviews.  Nearly  everyone  agreed  DMA  is  changing  to  accommodate 
real-world  situations  and  the  jump  to  CIS  technology.  How  they  think  DMA  should  undertake 
this  controversial  and  complicated  task  is  less  clear. 
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Every  interviewee  admitted  that  DMA  was  anticipating  requirements  in  the  DCW  case. 
The  power  of  the  intelligence  community  is  rising  within  the  DoD  and  DMA  sees  a  strong  need 
to  provide  them  with  more  support.  The  intelligence  community  is  involved  in  every  important 
national  contingency,  from  military  operations  to  the  continuing  battle  over  narcotics  trafficking. 
Their  role  in  these  situations  and  their  efforts  to  modernize  how  they  accomplish  their  tasks 
through  the  use  of  GIS  technology  has  earned  them  a  great  deal  of  respect.  Most  DMA 
personnel  believe  that  the  intelligence  agencies  see  DMA  as  unresponsive  to  their  needs  due  to 
DMA’s  pre-occupation  with  supporting  the  military  commands  and  services,  DMA  sees  an 
operational  need  to  support  the  intelligence  community  with  products  to  help  accomplish  their 
increasingly  important  and  highly  visible  mission.  DMA  also  sees  the  intelligence  community 
as  a  stepping  stone  to  the  military  community  in  the  commands  and  services.  Military 
commands  still  tend  to  depend  on  developing  specific  systems  and  requiring  specific  products 
for  those  systems  rather  than  taking  a  broader  perspective  of  digital  geographic  requirements. 
DMA’s  effort  to  support  GIS  activities  in  the  intelligence  community  and  to  aid  the  successful 
adaptation  of  GIS  technology  in  DoD  was  intended  to  help  change  the  military’s  mind  set. 

DMA  was  determined  to  execute  the  DCW  project  for  largely  self-serving  reasons. 
Because  GIS  users  were  mishandling  the  exploitation  of  a  new  technology  in  the  department 
through  individual  arrangements  with  GIS  contractors  for  systems  and  data,  DMA  believed  a 
digital  standard  for  GIS  data  was  needed.  In  DMA’s  view,  the  availability  of  large  standardized 
data  sets  was  also  necessary  to  influence  the  users  into  utilizing  the  new  GIS  databases.  DMA 
also  believed  prototyping  was  the  most  appropriate  methodology  for  use  in  this  development 
project  for  several  conflicting  reasons. 
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One  interviewee  at  DMA  Headquarters  stated  that  prototyping  in  the  DCW  project  was 
required  because  DMA  had  a  potentially  wide  user  base  for  GIS-related  products  and  prototyping 
offered  a  way  to  involve  many  users  at  one  time  in  a  development  project.  DMA  recognized 
that  the  DCW  project  was  a  break  from  the  traditional  method  of  developing  digital  mapping 
products  and  the  intended  user  of  this  product  was  not  a  single  entity.  Another  interviewee,  who 
worked  directly  on  the  DCW  project,  stated  that  prototyping  was  used  because  it  could  "shave 
development  time"  and  the  standards  and  database  were  needed  immediately.  These  differing 
perspectives  account  for  much  of  the  confusion  reflected  in  the  Statement  of  Work  and  other 
early  documents. 

Because  the  DCW  project  appears  to  have  generated  a  beneficial  product,  that  is  the 
product  standards  and  the  database,  a  strongly  positive  perception  of  prototyping  has  developed 
within  DMA.  In  addition,  the  availability  of  prototype  products  to  support  Operation  DESERT 
STORM  coincided  nicely  with  DMA’s  efforts  to  become  more  proactive  and  anticipate  their 
customer’s  requirements  for  products.  Intelligence  agencies  used  DCW  as  a  background  source 
at  several  briefings  for  the  highest  levels  of  government  during  Operation  DESERT  STORM. 
DCW-like  products  (1:1,000,000,  1:250, 0(X),  and  larger  scale  digital  products)  were  also 
deployed  in  limited  quantities  in  the  Kuwaiti  Theater  of  Operations.  One  interviewee  stated  that 
many  senior  DMA  managers  were  impressed  by  the  prototyping  process  for  this  reason  alone. 

DMA’s  perception  of  the  success  of  this  project  has  led  to  another  development  effort 
based  upon  the  "Digital  Products  Study"  (1990).  An  outgrowth  of  this  study  advocated  the  use 
of  the  Vector  Product  Standards  developed  along  with  DCW  to  build  a  group  of  digital  vector 
products  at  varying  scales  (1:250,000,  1:50,000,  and  larger).  This  project,  called  GEOMAP, 
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is  not  oriented  toward  any  specific  system  which  requires  the  data,  nor  is  there  any  written, 
formal  statement  of  requirements  from  any  users.  It  is  simply  an  attempt  '  ‘he  agency  to 
become  user  oriented,  support  the  rapid  introduction  of  GIS  into  DoD,  and  convince  the  user 
community  that  DMA  is  ready  to  produce  the  data  they  need  to  accomplish  their  missions. 
Developer 

Interviews  at  the  developer  level  were  primarily  with  the  project  manager  and  several 
others  involved  with  production.  The  ESRI  project  manager  communicated  a  wealth  of 
information  concerning  the  initial  design  efforts  by  the  contractor  as  well  as  a  summary  of 
up-to-the-minute  activities.  As  one  might  expect,  the  contractor  was  more  familiar  with  the 
nature  of  prototyping  and  had  a  better  comprehension  of  what  the  design  process  entailed.  They 
were  very  concerned  with  the  development  of  the  standard  and  the  production  problems 
encountered  in  the  normal  course  of  such  a  large  project. 

Early  discussions  with  the  project  manager  by  telephone  elicited  some  interesting 
perspectives  on  the  DCW  project.  The  lack  of  a  formal  user  needs  assessment  by  the  sponsor 
was  promptly  recognized  and  rectified  by  the  conduct  of  a  limited  formal  survey.  The  project 
manager  admitted  that  the  user  needs  inherited  from  DMA  at  the  start  of  the  project  were  "not 
what  we  had  hoped  for."  However,  he  also  stated  that  his  understanding  of  the  real  reason  for 
the  project  and  the  prototyping  effort  was  to  establish  a  GlS-oriented  digital  data  standard  as 
soon  as  possible.  This  would  allow  DMA  to  control  the  introduction  of  GISs  and  related  data 
sets  into  the  Department  of  Defense.  Certainly  the  commercial  value  of  being  associated  with 
the  DCW  project  in  this  regard  was  not  lost  on  the  contractor. 
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The  interview  at  the  DCW  contractor’s  site  provided  information  on  their  design 
methodology.  ESRI  had  long  realized  the  value  of  putting  a  concrete  example  of  their  proposed 
system  into  the  hands  of  the  entity  who  would  be  making  the  decision  on  awarding  contracts  for 
GIS  systems  and  related  products.  However,  these  examples  were  demonstrations  of  their 
system’s  capability  rather  than  a  true  prototype. 

In  the  database  design  methodology  used  by  this  company,  the  flow  of  effort  followed 
a  simple  path; 

1.  Determine  and  define  user  needs. 

2.  Perform  conceptual  design  of  the  database. 

3.  Perform  physical  design  of  the  database.  This  may 

include  the  use  of  prototypes. 

4.  Implement  the  design. 

The  project  manager  believed  that  the  need  to  carry  out  the  project  quickly,  within  a  two  year 
time  frame,  impacted  their  ability  to  perform  but  did  not  hinder  the  prototyping  itself.  The 
same  number  of  prototypes  could  easily  be  produced  in  the  allotted  time  frame,  in  his  view,  but 
the  number  of  meetings  to  discuss  their  efforts  could  have  been  reduced. 

It  is  interesting  to  note  that  the  development  team  was  able  to  devise  the  Vector  Product 
Standards  in  the  very  short  span  of  two  years.  Because  the  sponsor  (DMA)  contracted  for  this 
as  a  product,  a  small  team  was  able  to  bring  many  resources  to  bear  upon  problems  usually 
encountered  in  standards  development.  This  is  in  direct  contrast  to  most  other  standards 
development  efforts  which  are  initiated  as  joint  efforts  between  several  large  organizations.  The 
federal  Spatial  Data  Transfer  Standard  and  international  projects  such  as  the  North  Atlantic 
Treaty  Organization’s  Digital  Geographic  Information  Exchange  Standards  are  more  typical  of 
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the  latter  type  of  standards  development  project.  For  instance,  a  federal  committee  worked  for 
five  and  one  half  years  before  producing  a  draft  proposed  standard  for  digital  cartographic  data 
in  1987  (National  Committee  for  Digital  Cartographic  Data  Standards,  1987). 

Another  critical  factor  that  helped  speed  the  VPS  effort  was  that  the  standards  were  user 
oriented  rather  than  representing  exchange  standards  for  transfer  of  data  between  cartographic 
producers  such  as  DMA,  NOAA,  and  USGS.  A  user  oriented  standard  is  one  in  which  all 
parties  could  make  use  of  the  data  "as  is",  without  having  to  transform  the  data  at  either  end  of 
the  exchange  process.  In  the  view  of  ESRI,  implementation  of  the  Vector  Product  Standards  by 
production  of  a  database  according  to  the  new  standards  was  a  wise  move  by  the  DMA. 

Users 

At  the  start  of  the  Digital  Chart  of  the  World  project,  only  seven  users  were  involved. 
All  filled  out  the  User  Needs  Survey  (see  the  last  page  of  Appendix  6  for  a  list  of  the  users  and 
their  organizations  who  responded  to  the  survey).  This  group  grew  during  the  prototyping 
process  to  total  more  than  70,  cutting  across  a  broad  spectrum  within  the  Department  of 
Defense.  It  was  possible  to  conduct  on-site  interviews  with  three  users  participating  in  the  DCW 
development.  Consequently,  the  United  States  Army  Engineer  Topographic  Laboratory, 
represented  the  service  labs  who  participated,  the  United  States  Air  Force  Intelligence  Support 
Agency  which  serves  as  the  headquarters  component  that  deals  with  mapping,  charting  and 
geodetic  matters  for  the  Air  Force  and  represented  the  services,  and  the  Defense  Intelligence 
Agency  Military  Geography  Division  represented  GIS  users  in  this  study.  Several  other  shorter 
interviews  were  conducted  by  telephone. 
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Comments  by  this  group  varied  widely  and  were  representative  of  the  different  individual 
perspectives  of  each  interviewee.  The  service  headquarters  element  had  a  global  perspective  on 
mapping  and  charting  support  in  DoD.  However,  they  still  complained  about  the  way  in  which 
this  project  may  have  detracted  from  DMA’s  primary  mission  of  producing  products  for  specific 
requirements,  although  they  realized  the  importance  of  the  standards  development.  The  service 
laboratory  was  more  interested  in  their  own  products  and  complained  about  the  rapid  pace  of  the 
prototyping  effort.  The  CIS  users  welcomed  any  effort  to  produce  a  product  which  they  may 
use  but  remained  skeptical  about  the  way  in  which  the  developer  was  obtaining  and  responding 
to  input  from  the  field. 

Several  of  the  users  were  concerned  that  some  of  their  comments  on  the  different 
prototypes  had  not  been  acted  upon  and  were  seemingly  ignored.  They  also  felt  that  since  there 
was  no  formal  requirement  for  the  product,  and  the  specifications  were  being  derived  in  concert 
with  its  development,  that  the  contractor  had  a  license  to  discard  user  suggestions  that  were 
appropriate  but  might  prove  difficult  to  implement.  All  of  the  users  involved  in  the  prototyping 
process  agreed  that  the  pace  of  the  project  placed  undo  stress  on  them.  Most  mapping  offices 
within  the  commands,  services,  and  other  agencies  are  staffed  by  very  few  people,  it  is  common 
to  have  between  one  to  four  people  in  such  an  operation.  In  the  case  of  service  labs,  the  degr^ 
of  resources  which  can  be  allocated  to  a  project  such  as  this,  which  had  not  been  previously 
coordinated  within  one  of  the  budget  documents,  is  also  extremely  limited.  In  the  present  case 
the  Army  laboratory  could  only  afford  to  assign  two  people  to  the  review  process  and  of  these, 
one  was  only  minimally  involved. 
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All  of  the  interviewees  recognized  the  need  for  standards  as  well  as  the  need  for  DMA 
to  be  proactive  while  at  the  same  time  striving  to  maintain  the  level  of  support  required  by 
currently  fielded  systems.  The  Air  Force  service  reviewer  notably  called  for  an  end  to  system- 
and  time-specific  development  of  digital  mapping  data  in  favor  of  a  broader  approach  which 
would  be  capable  of  satisfying  a  wide  range  of  user  needs  with  a  single,  integrated  product  such 
as  a  master  database. 


Participants’  Perspectives  as  a  Building  Block 
Clearly  the  three  main  groups  of  participants  each  held  a  unique  perspective  on  the 
implementation  and  utility  of  prototyping  in  the  DCW  case.  Our  task  is  to  derive  a  set  of 
findings  and  recommendations  from  the  experiences  of  these  groups  to  evaluate  the  use  of 
prototyping  in  the  design  of  Geographic  Information  Systems  and  related  components. 
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CHAPTER  5 


LESSONS  LEARNED  FROM  THE  DIGITAL  CHART 
OF  THE  WORLD  PROJECT 

Several  findings  emerge  from  this  study  that  may  have  a  significant  impact  upon  the  way 
in  which  prototyping  operations  can  be  incorporated  in  the  GIS  design  process.  It  is  important 
to  document  these  findings  and  provide  recommendations  so  that  future  use  of  this  development 
technique  can  be  made  effective. 

Prototyping  in  the  DCW  Project 

Prototyping  as  implemented  in  the  DCW  project  was  intended  to  assist  DMA  in 
accomplishing  its  goal  of  developing  standards  for  vector  products  and  a  digital  spatial  database 
that  could  be  stocked  and  distributed  to  users.  However,  because  of  the  conflicting  reasons  for 
initiating  the  project  (as  stated  in  the  documentation  and  in  interviews  with  DMA  employees), 
the  DCW  development  project  can  not  serve  as  a  good  example  of  the  use  of  prototyping  as  a 
requirements  gathering  and  analysis  tool  in  GIS  design.  DMA’s  preconceived  agenda  for  the 
establishment  of  vector  data  standards,  the  contradictory  reasons  for  using  prototyping  in  this 
case,  and  the  neglect  in  developing  user  requirements  in  the  early  stages  of  the  development 
effort  violated  several  rules  for  the  effective  use  of  prototyping  in  system  design. 
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The  first  problem  arose  out  of  the  generation  of  a  product  (the  DCW  database)  which  no 
one  explicitly  required  while  quickly  trying  to  develop  a  digital  data  standard  for  topologically 
structured  data.  As  the  project  wore  on,  DMA  admitted  that  the  standard  was  the  most 
important  part  of  the  project  and  that  the  database  was  generated  to  support  the  adoption  of  the 
standard.  How  this  admission  may  have  colored  the  initial  content  of  the  product  and  the 
conventions  incorporated  in  the  digital  data  standard  is  unclear.  Since  most  users  recognized 
the  need  for  topologically  structured  data,  they  participated  in  the  definition  of  requirements  for 
the  database  even  though  few  had  firm  plans  to  use  it.  This  led  to  some  bad  feelings  between 
DMA  and  its  customers  which  could  have  been  alleviated  by  early  communication  of  the  real 
purpose  of  the  project.  If  the  real  reasons  for  the  development  project  were  admitted  by  DMA 
up  front,  the  debate  over  whether  prototyping  was  used  as  a  requirements  analysis  tool  or  as  an 
implementation  tool  may  be  moot,  despite  any  of  DMA’s  assertions  affirming  one  use  over 
another. 

Since  the  development  schedule  was  rushed  by  DMA’s  own  deadlines  and  the  User  Needs 
Survey  was  accomplished  only  after  the  prototyping  process  began,  the  users  faced  enormous 
difficulties  in  evaluating  and  responding  to  the  prototypes.  Communication  between  developer, 
sponsor,  and  user  was  inefficient  and  several  misperceptions  of  the  DCW  developed  and  were 
allowed  to  remain  in  place.  The  rapid  nature  of  the  DMA-imposed  schedule  may  have  also 
influenced  the  downstream  structure  of  the  database  as  well  as  the  standard  because  some  user 
inputs  were  submitted  too  late  for  incorporation  into  the  next  prototype. 

These  shortcomings  emphasize  three  lessons  to  be  learned  from  this  case  study  which  will 
lead  to  recommendations  for  the  future  use  of  prototyping  in  CIS  design. 
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DCW  Development  Project  Findings 


Three  crucial  violations  of  the  use  of  prototyping  as  a  requirements  analysis  tool  are 
illustrated  in  the  Digital  Chart  of  the  World  development: 


1.  The  initial  impetus  for  undertaking  this  design  project  and  the  reasons  for  the 
use  of  prototyping  were  not  well  defined  or  linked  to  an  assessment  of  the 
users’  requirements. 

2.  Communication  between  DMA,  ESRI,  and  the  users  was  hampered  by  the 
rapid  pace  of  the  project  and  the  lack  of  an  efficient  mechanism  for  effective, 
two-way  exchange  of  information. 

3.  Documentation  focused  on  the  activities  surrounding  the  issue  and  review  of 
the  prototypes  and  was  contradictory  and  incomplete  at  the  start  of  the  project. 


User  Requirements 

There  was  either  an  unwillingness  or  an  inability  on  the  part  of  the  developer  to  provide 
the  author  with  any  documentation  other  than  the  SOW  which  may  have  given  the  initial  impetus 
behind  DMA’s  DCW  project.  The  fact  that  DMA  was  anticipating  future  user  needs  was  well 
explained  and  justified  during  interviews  at  DMA;  however,  it  was  not  clear  in  the  documenta¬ 
tion  whether  the  requirement  for  the  DCW  product  or  the  standards  came  first.  It  seems  likely 
that  the  agency  felt  the  need  to  develop  user-oriented  digital  data  standards  first  to  control  the 
proliferation  of  GIS  in  DoD,  and  decided  the  best  way  to  carry  out  this  project  and  test  the 
standards  would  be  to  build  the  1:1 ,000,000  scale  DCW.  A  formal  survey  of  customers  making 
use  of  GIS  and  their  needs  for  data  and  digital  standards  before  the  initiation  of  the  development 
project  could  have  provided  significantly  more  focus  for  the  effort. 
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Because  DMA  believed  a  wealth  of  data  was  needed  to  enforce  the  standards,  the  ONC 
was  chosen  for  the  basis  of  the  global  digital  database.  The  ONC  series  could  provide  world 
wide  coverage  and  provide  large  amounts  of  data  to  help  ensure  the  standard  was  followed. 
However,  the  elementary  need  to  have  a  wealth  of  data  available  does  not  alleviate  the 
developer’s  responsibility  to  ensure  the  customers’  were  willing  to  use  the  data  to  be  produced. 
A  more  formal  definition  of  user  needs  prior  to  project  startup  may  have  shown  that  there  was 
no  need  for  the  DCW  product  itself,  but  that  the  users  were  willing  to  support  the  development 
because  they  understood  the  need  for  standards  (and  would  be  applying  the  standards  to  later 
production  of  other  databases).  This  type  of  survey  (a  survey  was  performed  during  the  "Digital 
Products  Study"  (1990),  half  way  through  the  DCW  project)  might  have  provided  good  support 
for  DCW  effort.  If  the  users  were  unclear  about  their  needs  in  the  survey,  it  could  have  been 
used  as  justification  for  development  of  a  digital  data  standard  and  may  have  helped  substantiate 
the  decision  to  proceed  with  prototyping  of  a  topologically  structured  database. 

In  this  case,  prototyping  was  used  either  to  ensure  that  the  standard  and  the  database  met 
the  requirements  as  defined  by  tlie  users  or  to  cut  development  time.  We  may  never  know  the 
real  reason  due  to  conflicting  statements  by  DMA.  A  strong  indication  that  the  use  of 
prototyping  was  more  an  effort  to  quickly  develop  a  product  that  was  acceptable  to  the  user,  as 
opposed  to  one  defined  by  them,  can  be  seen  in  the  fact  that  the  User  Needs  Survey  was 
completed  by  only  seven  users  and  that  the  results  of  the  survey  were  not  even  ready  before  the 
first  prototyjje  was  completed. 

The  first  prototype  was  delivered  in  December  1989  and  took  six  weeks  to  produce 
(Pre-Preliminary  Design  Review  Data  Package,  1990).  The  User  Needs  Survey  was  dated 
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November  1989  (see  Appendix  5),  and  the  Pre- Design  Concept  Review  Data  Package  (dated  09 
January  1990)  stated  that  a  sub-contractor  was  "assembling  a  synthesized  view  of  user 
requirements."  This  indicates  that  the  first  prototype  was  developed  with  little  or  no  user  input. 

Because  DMA  and  the  contractor  had  a  preconceived  idea  of  what  the  prototypes  ought 
to  look  like  before  any  of  the  users  were  involved,  questions  in  the  User  Needs  Survey  were 
framed  from  a  point  of  view  which  implied  that  the  development  of  the  DCW  was  a  foregone 
conclusion.  Instead  of  asking  what  the  user  needed,  they  were  asked  how  they  would  make  use 
of  the  DCW  (another  question  stated:  "[p]tease  indicate  the  information  classes  from  DCW 
which  you  will  use"  indicating  that  a  pre-selected  set  of  thematic  layers  existed).  Still, 
prototyping  did  work  to  modestly  increase  user  involvement  in  requirements  refinement  activities 
since  the  user  group  grew  from  the  original  seven  to  eventually  number  more  than  70  reviewers. 
Communication 

Perhaps  the  biggest  issue  identified  during  this  study  was  that  the  interaction  between 
DMA,  ESRI,  and  the  users  was  less  than  perfect.  Since  DMA  is  a  separate  agency  with  its  own 
charter  and  its  customers  are  outside  of  its  direct  control,  the  need  exists  for  a  fluid  and  early 
interaction  between  the  sponsor/developer  team  and  the  users.  During  project  planning, 
designers  must  properly  inform  users  as  to  what  to  expect  in  a  development  project  and  the 
rationale  for  those  actions.  They  must  also  focus  on  users’  requirements  from  the  start  by 
interacting  with  the  users  at  the  earliest  opportunity.  This  would  also  have  allowed  users  outside 
of  DMA  to  adequately  plan  for  their  participation  in  the  development  project. 

DMA  initiated  this  project  rather  suddenly,  taking  many  of  the  users  by  surprise.  DMA 
felt  it  was  responding  to  perceived  needs,  subsequently  justified  by  the  number  of  customers  who 
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expressed  an  interest  in  using  topologically  structured  data,  but  not  necessarily  the  DCW 
database.  Had  conditions  been  different,  DMA  might  have  been  better  served  by  lobbying  for 
one  or  more  users  to  submit  a  formal  requirement  for  DCW-like  digital  data  and  a  digital  vector 
data  standard.  This  would  have  appeased  many  of  the  feelings  among  the  services  and  the 
commands  that  DMA  had  sharply  moved  away  from  its  primary  role  of  providing  support  to  the 
operational  users  through  the  development  of  an  undesired  product. 

Better  communication  could  also  have  alleviated  the  stigma  of  the  DCW  as  a  research 
and  development  project  producing  a  spatial  database  that  might  be  put  on  the  shelf  due  to  lack 
of  interest.  Several  DMA  employees  admitted  that  customers  will  eventually  use  the  DCW 
database,  but  that  use  at  first  will  be  limited  to  intelligence  agencies  and  others  adopting  CIS 
technology.  DMA  strongly  feels  that  many  users  will  employ  other  digital  products  built 
according  to  the  VPS  as  a  result  of  the  Digital  Products  Study  and  the  GEOMAP  initiative, 
despite  the  fact  that  no  formal  requirements  have  been  expressed. 

Some  of  the  users  may  have  been  confused  about  the  required  level  of  their  participation 
in  this  ''R«&D"  project  because  they  did  not  know  it  was  being  planned,  nor  did  they  understand 
that  the  goal  of  developing  the  digital  data  standard  had  paramount  importance.  Notably  no  user 
involvement  was  funded  or  programmed  before  the  project  was  initiated.  Every  user  outside  of 
DMA  paid  their  own  way  to  the  meetings  and  provided  the  necessary  hardware  at  their  sites  to 
perform  the  reviews  of  the  prototypes.  Better  communication  between  the  sponsor/developer 
and  the  users  could  help  cultivate  a  relationship  where  prototyping  can  be  more  effectively 
carried  out. 
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Because  the  users  were  not  part  of  the  organization  performing  the  design  and 
development  work,  there  was  also  a  tendency  for  them  to  lose  track  of  the  status  of  the 
comments  and  input  they  provided  to  the  development  team  due  to  inadequate  two-way 
communication.  Many  users  stated  that  they  provided  what  they  thought  were  substantive 
comments  only  to  see  them  ignored  when  the  next  prototype  was  issued.  The  developer  stated 
that  many  times  comments  were  late  and  therefore  were  not  used  in  the  design  of  the  next 
prototype.  Clearly  communicating  this  situation  directly  to  the  users  through  some  sort  of 
formal  response  mechanism  would  allow  better  flow  of  data  on  subsequent  iterations.  The  user 
could  then  make  more  timely  submissions,  reiterate  points  he  felt  were  important  but  not  picked 
up  by  the  developer,  and  so  on. 

Along  with  requests  to  participate  in  the  review  of  prototypes,  a  more  detailed  plan  must 
be  included  in  any  prototype  project  to  unequivocally  inform  the  user  of  what  he  is  to  expect  and 
do.  The  first  letter  in  the  Pre-Design  Concept  Review  Data  Package  contained  very  little 
information  in  this  regard.  Several  of  those  invited  to  the  Design  Concept  Review  did  not 
receive  the  first  prototype  but  were  invited  because  they  had  expressed  an  interest  in  participat¬ 
ing  or  were  contacted  about  participating.  They  were  presumably  informed  about  their  role  in 
some  way. 

Finally  the  time  constraints  placed  on  this  project  were  the  subject  of  discussion  at  every 
inter\  '  w.  There  is  no  documented  reason  for  the  constraints  as  imposed  by  DMA  (at  least  none 
were  provided)  and  the  users  were  not  consulted  prior  to  the  establishment  of  the  schedule. 
Several  interviewees  stated  that  the  time  constraint  worked  against  their  individual  efforts  but 
was  favorable  to  the  overall  conclusion  of  the  project.  The  time  periods  between  development 
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of  prototypes  and  the  period  when  comments  are  due  should  accommodate  the  reviewers  as 
much  as  possible  but  should  also  be  set  within  written  criteria,  with  sound  reasons  provided  as 
a  background  for  these  decisions. 

Documentation 

Because  the  sponsors,  designers,  and  developers  were  most  concerned  with  the 
functionality  of  the  system  and  in  meeting  deadlines,  there  was  a  decided  neglect  with  respect 
to  documenting  what  had  taken  place.  As  soon  as  work  was  done  on  one  prototype,  work  began 
on  the  next  phase  without  going  back  to  adequately  document  activities.  Clearly,  complete 
design  documents  were  required  and  at  a  minimum  should  have  included  Data  Flow  Diagrams, 
Entity-Relationship  Diagrams,  and  perhaps  Control  Flow  Diagrams  to  substantiate  the  user 
requirements  for  the  software  and  the  conceptual  model  of  the  database.  This  presumes  the  flow 
of  the  design  process  was  organized  in  accord  with  modern  software  engineering  techniques  such 
as  structured  analysis  (e.g.  the  Marble-Wilcox  model). 

A  Prototyping  Model  for  CIS  Design 

A  methodology  which  relies  upon  prototyping  as  a  major  tool  for  the  definition  of  user 
requirements,  documentation  of  design  activities,  and  smooth  communication  of  system  functions 
and  goals  could  be  implemented  by  adapting  portions  of  the  design  methodologies  reviewed  in 
this  paper.  As  Marble  and  Wilcox  (1991)  state,  optional  pilot  studies  can  assist  in  determining 
user  requirements  but  are  not  often  used  because  they  are  expensive  (especially  when  modelling 
an  entire  system),  and  require  "expository  selection  of  CIS  software."  Prototyping  could  be 
used  in  place  of  pilot  studies  to  perform  user  requirements  analysis  in  the  implementation  of 
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small  systems,  where  Marble  and  Wilcox’s  cost  concerns  could  be  lessened.  The  development 
or  selection  of  GIS  databases  and  applications,  which  are  more  limited  in  scope  than  system 
implementation,  offer  even  better  opportunities  to  use  prototyping  to  benefit  GIS  design. 

Connell  and  Shafer’s  recommendations  for  using  CASE  tools  in  conjunction  with  a 
relational  database  management  system  (RDBMS)  to  demonstrate  proposed  solutions  to  user 
requirements  could  be  adapted  to  GIS  database  and  application  design.  For  example,  in  an 
application  development,  items  from  a  data  set  could  be  retrieved  using  the  RDBMS  and 
displayed  in  the  sample  screens  and  menus  (generated  using  CASE  tools)  to  model  the  operation 
of  the  program.  The  same  would  hold  true  for  the  development  of  a  GIS  database  since  the 
project  would  also  likely  include  software  to  allow  the  user  to  view  data  prior  to  his  development 
of  tools  or  systems  to  use  the  data.  A  tool  for  illustrating  the  spatial  dimension  of  queries  in  a 
graphic  environment  needs  to  be  developed  and  tied  to  this  methodology  for  use  in  GIS  design. 

The  iterative  process  illustrated  in  Figure  6  could  be  used  as  a  specific  procedure  to  begin 
the  development  of  a  GIS  database  or  application  design  project.  Activities  in  step  1  entail 
preliminary  contact  with  the  user,  a  first  cut  at  the  user  needs  assessment,  and  the  planning  (with 
the  user)  of  project  schedules  and  deliverables.  Next  the  organizational  implications  of  the 
proposed  project  must  be  evaluated  and  incorporated  into  a  listing  of  user  requirements  (step  2). 
Finally,  fourth-generation  tools  are  used  to  model  and  create  working  skeletons  of  the  proposed 
application  or  database  (step  3).  Iterative  prototypes  are  constructed  until  the  user  is  satisfied 
that  the  requirements  analysis  is  complete  (activities  in  step  2  may  need  to  be  revisited  and 
refined).  From  this  point,  more  traditional  methodologies  could  be  employed  to  perform 
application  specification  or  database  design  activities. 
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Prototyping  Model  for  GIS  Design 


The  proposed  methodology  outlined  above  would  maximize  the  advantages  of 
prototyping;  at  the  same  time,  care  must  be  taken  to  minimize  the  disadvantages.  Effective 
communication  between  developers  and  users  would  lead  to  an  improved  user  interface  and 
lessen  the  customer’s  false  expectations  from  the  prototypes.  Products  of  the  CASE  tool  (DFDs, 
ERDs,  and  CFGs,  along  with  the  proposed  spatial  display  screens)  would  significantly  aid  final 
specification  of  the  database  or  application  while  also  providing  a  degree  of  flexibility  to  the 
design  process. 

The  proposal  to  use  this  procedure  is  only  an  initial  attempt  to  take  advantage  of  the 
potential  that  prototyping  offers  to  GIS  design  through  the  enhancement  of  user  requirements 
analysis.  Prototyping  in  GIS  database  or  application  design  needs  to  be  tested  and  refined  using 
appropriate  procedures  and  constraints  before  it  is  widely  accepted.  The  results  of  the  DCW 
design  process,  though  not  a  good  example  of  the  prototyping  process,  illustrate  that  it  is  a 
viable  alternative  to  using  the  top-down  specification  model  in  all  GIS  design  projects. 
Increasing  the  interaction  between  designers  and  users  is  critical  to  successful  implementation 
of  Geographic  Information  Systems. 
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CHAPTER  6 


CONCLUSIONS 


This  study  of  the  Digital  Chart  of  the  World  development  project  looked  at  the 
use  of  prototyping  in  the  CIS  design  process  by  examining  the  adoption  of  a  rapidly  growing 
technology  (CIS)  in  the  unique  arena  of  the  Department  of  Defense.  Unfortunately,  this  study 
illustrated  that  prototyping  has  yet  to  make  a  transition  from  a  procedure  primarily  benefiting 
physical  implementation  activities  to  one  which  may  significantly  aid  Geographic  Information 
System  design  during  the  definition  and  refinement  of  user  requirements.  The  way  in  which 
prototyping  was  utilized  during  DCW  user  requirements  analysis,  the  poor  communication 
between  DMA,  ESRI,  and  users,  and  the  lack  of  effective  documentation  in  this  case  all  violated 
several  key  assumptions  of  prototyping. 

The  DCW  development  clearly  demonstrated  a  fragmented  approach  to  user  requirements 
analysis  but  indicates  that  prototyping  can  aid  in  the  definition  of  user  needs.  To  its  credit, 
prototyping  delivered  the  DCW  product  directly  to  the  user  at  various  incremental  levels  of 
detail  and  allowed  the  user  to  test  the  adequacy  of  the  database  and  make  recommendations  for 
changes  to  the  product  and  the  digital  data  standard.  However,  this  required  a  structure  for 
quick  and  efficient  interaction  between  the  user  and  the  developer/designer  team,  a  structure 
which  does  not  exist  within  the  DoD  Mapping,  Charting  and  Geodetic  community.  Communica¬ 
tion  throughout  the  project,  but  especially  at  the  start,  is  important  to  the  success  of  any 
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prototype  process,  especially  where  the  participants  are  from  different  organizations  requiring 
formal  interactions. 


Recommendations 

Several  recommendations  may  be  suggested  for  organizations  wishing  to  utilize 
prototyping  in  GIS  design  activities.  Each  recommendation  stems  from  a  finding  in  the  DCW 
case  study  but  has  universal  relevance  to  other  such  design  efforts,  whether  on  a  large  scale  such 
as  DMA’s  attempt  to  interact  with  its  customers  in  the  GIS  arena  or  one  firm’s  endeavor  to 
provide  its  client  with  a  beneficial  product. 

1.  The  initial  impetus  for  undertaking  a  design  project,  and  the  reasons  for  the 
use  of  prototyping  in  that  project,  must  be  well  defined  and  linked  to  the  need 
to  iteratively  develop  and  refine  the  users’  requirements. 

2.  Effective  communication  between  developer,  designer,  and  users  is  critical  to 
unqualified  success  in  a  prototyping  project. 

3.  Documentation  of  the  entire  process,  not  just  the  middle  and  end  where  more 
tangible  activities  occur,  is  crucial. 

Prototyping  can  most  effectively  be  used  as  a  requirements  analysis  tool  in  GIS  design  if  its 
capabilities  to  increase  interaction  with  the  users  and  to  iteratively  define  and  satisfy  user 
requirements  are  recognized  as  essential  at  the  start  of  a  project.  Once  the  decision  to  use 
prototyping  for  these  reasons  has  been  made,  project  managers  must  ensure  that  the  users  remain 
the  focus  of  the  development  effort  and  ensure  the  proper  environment  exists  to  maximize 
two-way  communication  between  parties.  Users  should  be  consulted  before  project  planning  is 
begun  so  that  they  are  aware  of  their  responsibilities  and  can  become  familiar  with  the  feedback 


69 


process.  The  developer  would  be  wise  to  establish  a  specific  mechanism  for  the  communication 
of  their  responses  to  the  users’  feedback  on  the  prototypes.  All  of  this  needs  to  be  clearly 
spelled-out  in  advance. 


Future  Work 

Prototyping  needs  to  be  tried  as  it  was  intended  to  be  implemented  by  Connell  and 
Shafer,  and  others,  before  it  is  judged  fully  capable  of  being  incorporated  into  GIS  design 
methodologies.  Coupling  prototyping  with  structured  design  methods  and  using  it  to  determine 
and  refine  user  requirements  from  the  outset  of  a  project  would  appear  to  offer  the  most 
potential.  At  this  point,  it  would  appear  best  suited  for  use  in  small-scale  projects  where  close 
control  can  be  exerted  over  the  users  and  designers  alike. 

A  test  should  be  developed  where  two  versions  of  the  same  GIS  component  (perhaps  an 
application  or  a  database)  will  be  designed  using  two  approaches;  one  group  could  use  a 
traditional  top-down  specification  model  like  the  Marble-Wilcox  model  while  another  group 
could  develop  a  product  using  a  structured  prototyping  process.  The  test  should  be  structured 
similarly  to  one  reported  by  Boehm,  et  al,  (1984),  but  must  provide  quantitative  results 
pertaining  to  measures  of  user  satisfaction  with  the  two  products  and  user  evaluations  of  the 
requirements  analysis  activities.  The  outcome  from  this  type  of  study  could  better  lead  one  to 
decide  whether  traditional  GIS  design  methodologies  should  be  altered  to  specifically  include  a 
place  for  prototyping.  It  may  also  lead  to  a  conclusion  as  to  whether  prototyping  may  be  the 
preferred  method  for  designing  databases  or  applications  in  GIS  development  projects. 


70 


Conclusion 


WhUe  .he  D,g.h..  Chan  of  ,he  WoHd  develop^en,  proved  .o  he  a  poor  example  of  U.e 

-  Of  pnno.^.,  as  a  re^s  a„a„s.s  .00,,  h  did  .ha.  pro.o.,pl„g  appears  « 

0  er  s.g„.fieao.  po.e„.ia,  for  adapu,lo„  .0  .he  G,S  desigo  process.  ,.  u  Khely  .ha.  wio. 

cohUnued  assessmen.  and  refinemen.,  pro,o.ypi„g  can  play  a  role  in  CIS  design,  similar  .0  oH.er 
software  engineering  techniques. 
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appendix  I 
interview  plan 


INTERVIEW  PLAN 


Objective; 

To  determine  the  effects  of  prototyping  on  the  Geographic  Information  System  database 
design  process  by  studying  the  Defense  Mapping  Agency’s  (DMA)  Digital  Chart  of  the  World 
(DCW). 

Likely  Effects: 

Beneficial 

-  Increased  user  involvement  in  the  development 

effort  (feedback) 

-  Well  defined  user  requirement 

-  Working  models  aid  definition  of  user 

requirement 

-  Users  can  articulate  what  they  don’t  want 

better  than  what  they  need  the  system  to  do, 
especially  when  they  have  a  model  to  work 
with 

-  Better  allocation  of  production  resources 

resulting  from  prototypes 

-  Users  may  want  to  be  more  involved  in 

prototyping  other  products 

Disadvantageous 

-  Too  much  effort  needed  from  overworked  user 

during  evaluation  (time) 

-  Management  restrictions  on  user  participation 

(travel  money,  time) 

-  Misunderstanding  that  the  prototype  tested  may 

not  be  the  system  delivered 

-  Users  may  want  to  be  more  involved  in 

prototyping  other  products 

Topics  to  Cover: 

1.  Position  and  responsibilities 

2.  Level/type  of  involvement  with  DMA 

3.  Level/type  of  involvement  in  evaluation  of  DCW 

prototypes 

4.  Impacts  of  prototyping 

5.  Evaluation  of  DCW  project 


Lead  Statement: 


"Mr.  Smith,  as  you  know,  I  am  a  graduate  student  studying  the  impact  of  rapid 
prototyping  on  the  development  of  Geographic  Information  Systems  and  databases.  Today  I’d 
like  to  take  the  next  hour  or  so  to  review  with  you  your  position,  your  interaction  with  DMA 
and  how  you  view  the  development  of  the  DCW." 

Lead  Questions: 

Topic  1.  Let  s  begin  with  your  position  and  your  major  responsibilities." 

Topic  2.  How  do  you  participate  in  DMA  product  development?" 

Topic  3.  I  d  be  interested  in  your  role  in  the  DCW  evaluation  project." 

Topic  4.  J’How  do  you  view  the  impact  of  rapid  prototyping  in  the  DCW  project?" 
Topic  5.  "Let’s  summarize  by  discussing  your  views  on  rapid  prototyping  and  the  results 
of  the  project, " 

Follow  Up  Questions: 

Topic  1.  '  How  long  in  present  job 

-  Background  and  training 

Topic  2.  -  Can  you  break  down  the  percentage  of  your 
job  spent  interacting  with  DMA 

-  How  would  you  classify  your  interactions 

(operational,  research,  etc.) 

Topic  3.  -  How  did  you  get  involved  in  the  DCW 
project 

-  How  much  time  could  you  devote  to  the 

evaluation  of  the  prototypes 

-  Tell  me  about  the  priority  you  assigned 

the  DCW  project 

Topic  4.  -  What  are  some  of  the  impacts  from 
prototyping  on  the  product 

-  What  are  some  of  the  impacts  from 

prototyping  on  you  and  your  organization 
Topic  5.  -  How  well  do  you  think  user  requirements 
were  met 

-  What  are  your  plans  for  using  the  DCW 
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LIST  OF  interviews 


LIST  OF  INTERVIEWS 


Kenneth  Brunjes,  Defense  Intelligence  Agency,  Military  Geography  Division. 

Irvin  Buck,  Defense  Mapping  Agency  Headquarters,  Acting  Assistant  Deputy  Director,  Plans 
and  Requirements  Directorate. 

David  M.  Danko,  Defense  Mapping  Agency  Systems  Center,  Digital  Chart  of  the  World 
Contracting  Officer  Technical  Representative. 

Louis  Fatale,  U.S.  Army  Engineer  Topographic  Laboratories,  Digital  Concepts  Analysis  Center. 


Lieutenant  Colonel  Paul  G.  Foley,  U.S.  Army,  Defense  Mapping  Agency  Headquarters,  Plans 
and  Requirements  Directorate,  Land  Combat  Division. 

Glen  Hill,  Environmental  Systems  Research  Institute,  Digital  Chart  of  the  World  Production 
Manager. 

Rosanne  T.  Hynes,  Defense  Mapping  Agency  Systems  Center,  Research  and  Engineering  Office. 


Dean  Karsok,  Environmental  Systems  Research  Institute,  Digital  Chart  of  the  World  Project. 

Duane  Niemeyer,  Environmental  Systems  Research  Institute,  Digital  Chart  of  the  World  Project 
Manager. 

Christinia  Pappas-Moir,  Defense  Mapping  Agency  Systems  Center,  Research  and  Engineering 
Office. 

Juan  Perez,  U.S.  Army  Engineer  Topographic  Laboratories,  Digital  Concepts  Analysis  Center. 

Neil  Sunderland,  U.S.  Air  Force  Intelligence  Support  Agency,  Mapping,  Charting  and  Geodesy 
Division. 
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SUMMARY  OF  THE 
DIGITAL  CHART  OF  THE  WORLD, 
FINAL  MILITARY  STANDARD, 
VECTOR  PRODUCT  STANDARD 


MIL-STD-600006 


4.  GENERAL  REQUIREMENTS 

4.1  General .  Vector  product  format  (VPF)  is  a  generic 
geographic  data  model  designed  to  be  used  with  any  digital 
geographic  data  in  vector  format  that  can  be  represented  using 
nodes,  edges,  and  faces.  VPF  is  based  upon  the  georelat ional 
model,  combinatorial  topology,  and  set  theory. 

4.2  VPF  characteristics.  VPF  is  designed  to  provide 
flexibility  in  encoding,  directly  accessing,  and  modeling  digital 
geographic  databases  for  a  variety  of  applications  on  different 
computer  systems.  VPF  characteristics  are  as  follows: 

a.  Sheetless  database  support.  VPF  is  designed  to  support 
a  sheetless  database  by  providing  logically  continuous 
topological  relationships  even  when  the  database  is 
physically  partitioned  into  tiles.  VPF  structures 
support  the  query  and  retrieval  of  data  that  extends 
across  tile  boundaries. 

b.  Neutral  format .  VPF  has  a  neutral  product  format  that 
is  used  in  combination  with  individual  product 
specifications.  VPF  is  topologically  structured  and 
supports  various  levels  of  topology,  from  simple 
cartographic  vectors  to  polygon  coverages  with  full 
two-dimensional  cell  topology. 

c.  Attribute  support .  VPF  uses  relational  tables  for 
attribute  handling.  Such  tables  support  both  simple 
and  complex  feature  types. 

d.  Data  dictionary.  VPF  contains  a  self-defining  data 
dictionary  and  lookup  tables  that  provide  a  schema  for 
user  understanding  of  features  and  their  attributes. 

e.  Text  and  metadata  support .  Text  information  may  be 
either  attributes  of  features  or  "free  floating" 
cartographic  primitives.  VPF  is  compatible  with  the 
use  of  all  written  languages,  including  accented 
characters  and  diacritical  marks.  In  addition  to  basic 
cartographic  information,  VPF  supports  a  variety  of 
metadata  files  for  carrying  supportive  information 
concerning  all  or  part  of  the  database. 

f.  Index  file  support.  Any  index  files  necessary  to 
enhance  database  retrieval  performance  are  also 
utilized  within  VPF,  These  can  include  spatial, 
thematic,  disk  location,  tile,  and  gazetteer  indices. 
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g.  Direct  use.  VPF  allows  application  software  to  read 
data  directly  from  storage  media  without  prior 
conversion  to  a  working  format.  VPF  uses  tables  and 
indices  that  permit  direct  access  by  spatial  location 
and  thematic  content. 

h.  Flexible,  general-purpose  schema.  VPF  can  represent 
digital  geographic  data  in  vector  format  by  providing 
flexibility  in  the  modeling  of  any  of  data 
organization,  from  fully  layered  to  completely 
integrated.  VPF  supports  two-dimensional  and  three- 
dimensional  coordinates,  multiple  scales,  and  the 
creation  of  multiple  products. 

i.  Data  quality.  VPF  includes  standards  for  data  quality 
reporting  and  representation.  It  provides  multiple 
methods  for  the  representation  of  the  spatial  and 
aspatial  aspects  of  data  quality. 

j.  Feature  definitions.  VPF  organizes  features  and 
thematic  attributes  to  ensure  logical  consistency  and 
completeness . 
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4.3  Relationship  between  VPF  and  specific  products.  The 
definition  of  data  content  shall  be  established  in  product 
specifications.  VPF  establishes  a  standard  data  model  and 
organization,  providing  a  consistent  interface  to  data  content. 
The  product  specification  determines  the  precise  contents  of 
feature  tables  and  their  relationships.  VPF  can  also  accommodate 
additional  tables  that  are  not  required  by  VPF  itself.  Figure  1 
illustrates  the  relationship  between  VPF  and  specific  products. 


Contents 


Forms 


Products 


Applications 


End  User 


FIGURE  1. 


Relationship  between  VPF  and  specific  products. 
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4.4  VPF  hierarchy.  A  VPF  database  can  be  viewed  as  a  five- 
level  hierarchy  of  definitions  (figure  2) .  This  document  explains 
VPF  as  a  collection  of  the  bottom  four  of  these  levels. 

The  top  level,  which  contains  the  product  specification,  is  used 
to  tailor  VPF  to  create  the  required  product. 


The  document  has  been  organized  to  begin  with  the  conceptual 
components  and  introduce  more  technical  details  in  later  sections. 
Section  5.2  defines  the  objects  that  are  used  in  a  database  within 
the  VPF  data  model.  The  data  structures  (section  5.3)  define  the 
mandatory  implementation  details  in  order  to  manipulate  VPF  data. 
This  section  fully  details  the  concepts  expressed  in  the  data 
model  section.  Encapsulation  Is  defined  in  section  5.4,  where  the 
data  structure  fields  are  identified.  The  data  syntax  described 
in  section  5.5  represents  the  set  of  rules  that  governs  the 
contents  of  the  fields. 


PROTOTYPE  4  EVALUATION  INSTRUCTIONS 


To  conduct  the  evaluation,  you  will  need  the  following  items; 

•  A  PC  with  Prototype  4  software  loaded  and  running 

•  A  CD-ROM  drive  with  the  proper  Prototype  4  CD-ROM  disc  loaded 

•  A  printed  copy  of  all  the  charts  used  in  this  prototype: 

-  ONCE-1 

-  ONCF-1 

-  ONCG-1 

-  ONC  G-2 

•  Plots  depicting  the  data  available  in  the  Prototype  4  database.  The  plots  '.vill 
consists  of  halves  of  the  ONC  sheets.  Half  sheets  of  the  ONCs  were  plotted  ;; 
order  for  the  plots  to  be  represented  at  compilation  scale  (1:1 .000,000)  and 
projection.  TTie  plot  of  F-1  displays  the  eastern  half  of  the  sheet,  w  hile  the 
plots  of  G-1  and  G-2  will  display  the  western  halves.  The  plot  of  the  E- 1 
sheet  is  centered  on  the  United  IGngdom. 

•  The  Prototype  4  Evaluation  Form 

Before  you  begin  the  evaluation,  we  suggest  that  you  examine  the  plots  and  pnnted  ni.ips 
establish  a  mental  context  for  the  geographic  areas  captured  for  Prototype  4. 

The  hard  copy  plots  have  beenprovided  to  allow  you  to  determine  whether  the  chan 
contents  have  been  accurately  and  completely  captured.  Feel  free  to  make  not^s  on  the 
plots  as  you  evaluate  the  prototype;  the  plots  serve  as  a  reference  to  information  within  the 
database.  After  the  CDR.  you  may  want  to  retain  the  plots  for  use  within  your  agencies. 

The  plots  and  their  corresponding  source  charts  have  consistent  scales  and  projections. 
they  may  be  overlaid  on  a  light  table  for  comparison  purposes.  Note  that  since  the  default 
display  is  generally  projected  on  the  screen  by  using  a  different  projection,  the  shape  of 
map  features  on  the  display  and  the  plots  will  be  different. 

We  suggest  that  you  conduct  an  extensive  evaluation  of  Prototype  4.  The  results  of  this 
evaluation  will  be  the  last  to  be  incorporated  into  the  DCW  product. 


Emphasis  of  Prototype  4  Evaluation 

The  intent  of  these  instructions  is  to  focus  your  attention  on  those  aspects  of  Prototype  4 
which  are  new  to  the  design  of  the  DCW.  The  issues  that  have  been  identified  represent 
additions  and  modifications  that  have  been  implemented  in  the  DCW  design  since  the 
release  of  Prototype  3.  As  most  of  these  changes  were  the  direct  result  of panicipant 
responses  to  previous  prototypes,  it  is  hoped  that  this  focused  approach  to  the  Prototype  4 
evaluation  will  sustain  the  progress  we  are  making  toward  the  development  of  the  DCW 
product. 


Evaluators  may.  of  course,  comment  on  any  aspect  of  the  prototype.  However,  we  w  ish  to 
encourage  you  to  focus  on  identifying  specific  problems  in  the  performance  or  content  of 
the  prototype.  As  this  is  a  prototype  development  w'ith  demonstration  softw-are.  problems 
in  the  implementation  of  the  DCW  design  are  certain  to  exist,  and  we  greatly  appreciate 
your  assistance  in  identifying  them. 


Prototype  Evaluation  Issues 


1.  DCW  Elevation  Data.  Prototype  4  introduces  a  new  approach  to  the  representation 
of  elevation  data.  While  the  point  and  line  coverages  within  the  hypsography  layer  remain 
largely  the  same,  the  content  of  the  polygon  coverage  has  been  revised.  The  polygon 
coverage  for  the  hypsography  layer  in  this  prototype  contains  six  elevation  zones.  As 
discussed  at  the  PDDR,  zones  captured  for  this  prototype  were  selected  because  they  reflect 
important  distinctions  with  respect  to  several  natural  and  cultural  factors.  These  factors 
include:  vegetation  patterns,  agricultural  uses,  population  distribution,  equipment 
peiformance,  and  human  health  and  comfort.  Please  examine  the  elevation  data  contained 
in  the  Hypsography  and  Hypsography  Supplemental  layers  and  comment  on  the  follow  mg 
issues: 

a.  Are  the  zones  contained  in  the  hypsography  polygon  coverage  able  to  prov  ide 
utility  as  a  tool  for  GIS  applications? 

b .  Does  the  software  allow  the  user  to  query  contour  data  and  shade  contour 
intervals? 

c .  Does  the  polygon  shading  functions  for  contour  zones  execute  properly 


2,  Thematic  Layers.  Prototype  4  contains  four  thematic  layers  that  were  not  available 
in  previous  prototypes:  Vegetation,  Landmarks,  Transportation  Structure,  and  Drainage 
Supplemental.  These  layers  contain  features  that  have  been  added  to  the  DCW  design  since 
the  last  prototype.  For  Ffototype  4.  the  contents  of  these  layers  are  presented  for  ONC 
Sheet  F-01  only. 

The  Vegetation  layer  contains  those  areas  labeled  as  "vegetation "  or  "clearing"  on  ONC 
sheets.  The  Landmarks  layer  contains  a  variety  of  point  and  polygonal  features  that  have 
been  captured  on  ONC  sheets  because  of  their  visual  prominence.  The  Transponation 
Structure  layer  contains  a  variety  of  transponation  features  that  have  been  added  to  the 
DCW  design  to  supplement  the  Road  and  Railroad  layers.  Finally,  the  Drainage 
Supplemental  layer  contains  those  small  lakes  and  small  inland  water  islands  that  fell  below 
the  minimum  polygon  size  established  for  the  DCW. 

For  a  complete  Uhing  of  the  features  contained  in  these  thematic  layers,  please  refer  to  the 
Draft  DCW  Product  Specification.  The  design  intent  in  capturing  these  layers  was  to 
complement  the  content  of  the  DCW  database  without  compromising  its  integrity.  Plea.ve 
review  the  contents  of  these  thematic  layers  with  this  in  mind  and  comment  on  the 
following  issues: 

a.  Do  the  features  contained  in  these  layers  provide  a  valuable  addition  to  the  DCW 
database? 

b.  Does  the  organization  of  these  layers  in  DCW  design  satisfy  the  requirements  of 
your  organization? 


3.  Software  Functionality.  Prototype  4  represents  the  final  functionality  of  the  DCW 
software.  The  focus  of  future  modifications  to  this  software  will  be  internal  engineenng 
and  performance  enhancement.  There  have  been  a  number  of  refinements  and  additions  to 
the  software  functionality  since  the  last  prototype.  Many  of  the  comments  received  from 
participants  concerning  ftototype  3  software  have  been  incorporated  into  this  final  soft'Aare 
design. 

Presented  below  is  a  partial  list  of  the  functions  that  have  been  added  to  the  DCW  softvvare 
design  since  the  last  prototype: 

•  Zoom  -  Users  will  now  be  able  to  zoom  in  and  out  of  the  DCW  database.  The 
zoom  capability  may  also  be  used  to  move  from  the  DCW  Browse  map,  which  is  the  tirst 
data  set  visible  to  the  user,  to  the  more  detailed  DCW  data  set  and  vice  versa. 

•  Help  -  Users  now  have  access  to  a  Help  option.  Help  is  available  at  both  the  main 
and  pull-down  menu  levels.  To  access  the  Help  windows,  hold  down  the  right  button  on 
the  mouse  or  the  FI  key. 

•  Generated  Graphics  -  Users  may  now  generate  two  types  of  graphics:  ( 1 1  a 
laiitude/longitude  grid  and  (2)  a  scale  bar. 

•  Status  Windows  -  This  software  contains  status  windows  that  notify  the  user  vv  hen 
software  operations  (e.g.  drawing,  initializing)  are  being  performed. 

•  Selection  by  Pointing,  Latitude/Longitude,  or  Placename  -  Users  may  now  select  a 
viewing  area  by  pointing  at  any  geographic  location  on  the  Browse  map.  They  may  also 
establish  their  viewing  area  by  entering  latitude/longitude  positions  or  place  names. 

•  Text  Reports  -  Users  may  now  produce  three  types  of  text  reports.  The  Feature 
Location  List  and  the  Area  Content  Summary  contain  attribute  information  for  selected 
features  within  a  specific  study  area.  The  Feature  Location  List  provides  a  repon  of  the 
location  of  these  attributes,  while  the  Area  Content  Summary  provides  a  repon  of  their  type 
and  count.  The  IFACC  correspondence  repon  contains  a  comparison  table  of  the  DCW  and 
IFACC  coding  schemes. 

•  Spatial  Query  -  By  pointing  to  a  geographic  location  on  the  screen,  users  can 
identify  the  attribute  characteristics  of  displayed  features. 

•  Postscript  interface  -  Users  can  now  generate  a  Postscript  plot  file  of  the  selected 
features.  Access  to  this  function  is  via  the  Hardcopy  option  under  the  Graphics  menu. 

Please  examine  tlie  functionality  of  Prototype  4  software  and  comment  on  its  new 
capabilities  as  listed  above. 


4.  Symbology.  Prototype  4  introduces  several  changes  to  DCW  symbology.  As  with 
Prototype  3,  this  protot^e  includes  a  full  default  symbol  set,  which  can  be  altered, 
completely  replaced,  or  added  to  by  the  DCW  users.  Other  advances  have  also  been  made 
in  the  areas  of  text  and  feature  symbology. 

The  overall  objective  in  developing  the  symbology  for  the  DCW  has  been  to  design 
symbology  that  helps  reduce  clutter.  One  of  the  principal  changes  in  the  symbology  since 
Prototype  3  has  had  as  its  objective  the  reduction  of  "text  clutter."  In  Prototype  4,"text  is 
scaled  directly  in  proportion  to  the  source  ONC  text.  The  size  of  the  text  is  related  to  the 
zoom  factor  selected  by  the  user.  Text  is  always  displayed  regardless  of  the  display  scale, 
but,  to  avoid  the  clutter  problem  at  small  scales,  text  will  appear  as  a  row  of  pixels.  .As  tiie 
user  operates  the  zoom  function  to  increase  the  display  scale,  the  size  of  the  text  increases 
proportionally.  Text  becomes  increasingly  legible  with  each  successive  zoom. 

The  user  may  also  alter  the  color  used  for  the  text.  Providing  this  functionality  was 
essential  to  aillow  the  user  a  free  choice  of  color  for  areas;  if  only  default  colors  were 
available  for  text,  a  user  wishing  to  display  areas  and  text  simultaneously  would  have  to 
avoid  the  default  text  colors. 

Several  additions  have  been  made  to  the  feature  symbology  set.  Prototype  4  contains  a 
digital  version  of  almost  all  of  the  point  symbols  from  the  ONC  source.  Some  of  these 
symbols  will  need  to  be  redesigned  for  the  final  product,  but  all  are  included  for  your 
evalutation. 

Primarily  because  of  the  limits  of  screen  resolution,  line  symbology  remains  less  than  ideal 
The  ability  to  display  different  line  patterns  is  limited  because  of  the  substantial  degree  oi 
clutter  that  results.  However,  the  quality  of  "dot"  and  "dash"  line  patterns,  which  are  now 
software  generated,  has  been  substantially  improved  for  this  prototype.  The  selection  of 
line  color  and  thickness  will  provide  the  most  valuable  tool  for  the  user  to  optirruze  line 
symbology. 

Perhaps  the  most  important  development  in  Prototype  4  feature  symbology  is  the  new 
approach  to  area  fill.  Area  symbology  in  Prototype  4  makes  exclusive  use  of  the  "pixel 
mixing"  technique  that  was  presented  at  the  Project  Detail  Design  Review  (PDDR).  The 
user  can  select  the  various  color  fills  through  the  Change  Symbology  menu  by  indicating 
the  desired  colors  and  designating  which  of  the  four  pixels  that  color  should  fill.  Color  nil 
is  intended  to  replace  cross  hatching  and  other  bold  pattern  fills,  which  have  been 
eliminated  from  the  symbology  design.  The  decision  to  avoid  area  fills  that  use  cross 
hatching  or  other  pattern  techniques  reflectes  our  view  that  patterning  adds  substantial 
clutter  to  the  screen  while  adding  very  little  to  the  readability  of  the  map. 

Please  examine  the  symbol  set  presented  with  this  prototype  and  comment  on  the  follow  ing 
issues: 

a.  Does  the  available  symbol  set  meet  user  requirements? 

b.  Does  the  Change  Symbology  menu  selection  adequately  suppon  the  user  s 
capability  to  design  symbology? 

c .  Do  the  changes  in  text  and  feature  symbology  improve  the  display  of  DCW  data  ’ 


5.  Browse  Map.  For  Prototype  4,  a  Browse  map  has  been  introduced  into  the  DCW 
design.  It  replaces  the  index  map  provided  with  the  previous  prototype.  The  Brow.se  map 
has  been  designed  to  serve  four  main  functions:  ( 1 )  to  provide  a  base  map  for  the  DCW 
stan-up  screen;  (2)  to  provide  a  user-defined  index  base  map  for  the  DCW;  1 3)  to  pro\  ide  a 
base  map  for  the  display  of  metadata;  and  (4)  to  provide  a  bounding  geographic  ai  ea 
context  to  suppon  zoom-outs.  In  operating  the  Browse  map.  users  should  be  able  to: 

•  Select  a  specific  area  of  the  DCW  to  examine  in  greater  detail 

•  Manipulate  the  zoom  function  to  move  from  the  Browse  map  data  set  into  the 
DCW  data  set  and  back  out  again 

•  Retrieve  metadata  (e.g.,  compilation  dates,  data  volumes,  and  data  availabilits  i 
from  the  DCW  data  set. 

Please  examine  the  capabilities  of  the  Browse  map  and  comment  on  the  following  issue: 

a.  Does  the  Browse  map  provide  an  effective  tool  for  the  selection  of,  and 
movement  between,  specific  study  areas? 

b .  Please  provide  recommendations  for  additional  meta-data  that  you  may  require  ’ 


6.  Data  Accuracy.  For  Prototype  4,  a  new  rule  has  been  adopted  for  the  represen  union 
of  small  polygonal  features.  In  previous  prototypes,  polygonal  features  with  a 
circumference  of  less  than  0.12  inch  were  eliminated  from  the  polygon  layers  of  the 
database.  These  features  were  eliminated  because  they  fell  below  the  minimum  polygon 
size  that  could  be  resolved  during  the  automation  process. 

In  response  to  panicipant  concerns,  a  new  procedure  has  been  adopted.  For  ONC  Sheet 
F-1.  small  polygonal  features  that  were  eliminated  from  Prototype  3  because  they  could 
not  be  captured  as  polygons  have  been  convened  to  point  features  and  retained.  To 
examine  these  point  features,  select  a  study  area  within  the  border  of  sheet  F-1  and  displa> 
the  point  coverages  from  the  Drainage,  Political/Oceans,  and  Hypsography  Supplemental 
layers.  Please  review  the  representation  of  -hese  features  and  comment  on  the  following 
issue: 

a.  Do  these  features  provide  a  valuable  addition  to  the  DCW  database  !’ 

b .  Does  the  organization  of  these  layers  in  the  DCW  design  satisfy  the  requirements 
of  your  organization? 


7.  Edgematching.  Prototype  4  represented  the  first  opponunity  to  employ  and  examine 
edgematching  procedures  for  the  DCW  because  it  is  the  first  prototype  to  contain  adjacent 
ONC  sheets.  In  developing  edgematching  procedures,  three  issues  were  identified: 

1.  Lxxiational  Issues.  Certain  features,  primarily  linear  features,  do  not  match  across 
module  boundaries.  When  mismatches  occur,  the  linear  features  from  the  less 
accurate  module  are  matched  to  those  in  the  more  accurate  module. 

2.  Connectivity  Issues.  There  is  a  certain  amount  of  overlap  between  adjacent  ONC 
sheets.  Because  the  sheets  have  different  compilation  dates,  the  features  w  ithin  the 
overlap  area  will  not  match.  Generally,  only  the  recent  sheet  will  be  used  as  a  data 
source. 


3.  Attribute  Code  Issues.  Because  of  different  compilation  dates,  attribute  codes 
may  change  across  module  boundaries.  When  this  occurs  with  linear  features,  a 
pseudonode  is  placed  on  the  module  boundary  and  the  linear  features  are  coded 
separately.  When  this  occurs  with  polygonal  features,  the  polygon  is  split  along  the 
module  border  and  the  faces,  as  well  as  their  composite  edges,  are  coded  separateU 

The  results  of  the  procedures  adopted  to  address  these  issues  can  be  examined  by  focusing 
on  the  border  areas  between  ONC  sheets.  For  example,  the  border  between  sheets  G- 1  and 
G-2  is  useful  for  examining  linear  edgematching  within  the  hypsography  and  road  layers. 
Where  edgematching  has  been  performed  on  the  roads  layer,  the  resulting  linear  feature  a  ill 
be  coded  as  a  that  which  was  compiled  from  an  adjacent  source.  The  border  between 
sheets  F- 1  and  G- 1  is  useful  for  examining  polygonal  features  in  the  hypsography  and 
drainage  layers.  Because  it  is  possible  to  display  the  latitude/longitude  grid  on  the  screen,  a 
should  be  easy  to  identify  the  border  between  ONC  sheets.  Please  examine  those  areas  of 
the  prototype  which  are  subject  to  edgematching  and  comment  on  the  following  issue: 

a.  Do  the  edgematching  procedures  adopted  for  the  DCW  appear  to  maintain  the 
continuity  of  features  across  ONC  sheet  boundaries? 

b .  .Are  the  ONC  data  coded  correctly  near  sheet  boundariesl* 


8.  Tiling  Structure.  Prototype  4  represents  the  first  implementation  of  a  tiling  scheme 
for  the  DCW.  While  the  tiling  scheme  is  largely  invisible  to  the  user,  it  is  of  tremendous 
interest  because  of  its  role  in  database  management  and  its  impact  upon  performance. 

Prototy  pe  4  contains  two  tiling  schemes  for  evaluation:  a  5°  by  5°  data  partition  and  a  3  ■  b> 
3“  data  partition.  The  area  of  these  tiles  may  be  viewed  on  screen  while  features  are  being 
drawn.  Features  are  drawn  to  the  screen  within  the  extent  of  each  tile.  For  a  graphic 
representation  of  these  tiling  schemes,  please  refer  to  Figures  7  and  8  in  the  Draft  DCW 
Product  Specification. 

As  discussed  in  the  Final  Tile  Design  Study  (CDRL  BOOl),  ESRI  is  recommending  that  a 
fixed  tiling  scheme  be  adopted  for  the  DCW.  However,  a  decision  concerning  the  size  of 
the  tiles  is  being  withheld  until  we  conduct  a  thorough  examination  of  the  performance  of 
Prototype  4.  As  a  result  of  our  initial  examination  of  Prototype  4,  we  are  considering  the 
use  of  larger  tiles  (e.g.,  7°  by  7°  or  10°  by  10°).  This,  we  feel,  might  substantially  reduce 
the  number  of  data  files  and  improve  performance.  While  the  choice  of  tile  size  w  ill.  of 
course,  be  driven  by  all  of  the  factors  identified  in  the  Tile  Design  Study,  we  welcome  y  our 
comments  on  the  following  issue: 

a.  Do  the  tile  sizes  available  in  this  prototype  adequately  meet  your  needs  for  the 
display  of  data  or  does  your  work  lend  itself  toward  the  use  of  larger  or  smaller 
dies?  , 


9.  DCW  Packaging.  The  DCW  packaging  design  has  undergone  considerable  revision 
since  Prototype  3.  The  design  presented  with  this  prototype  is  much  closer  to  the  final 
design  which  will  accompany  the  completed  DCW  product. 


The  CD-ROM  pamphlet  is  very  similar  in  content  to  the  pamphlet  distributed  with 
Prototype  3  but  differs  noticeably  in  appearance.  The  packaging  effon  has  focused  on 
designing  a  recognizable  "look"  for  the  DCW  which  would  be  functional  for  all  elements  ot 


the  DCW  product.  In  response  to  participant  comments,  the  design  has  evolved 
significantly  since  Prototype  3. 

For  this  design,  the  front  cover  of  the  pamphlet  displays  the  Robinson,  rather  than  an 
azimuthal,  world  map  projection.  The  back  cover  of  the  pamphlet  now  displays  the 
geographic  area  covered  by  the  database  on  the  CD-ROM  rather  than  a  list  of  participants 
Because  the  previous  pamphlet  was  too  thick,  this  pamphlet  was  reformatted  to  displav 
print  on  both  sides. 

The  primary  change  in  the  content  of  the  pamphlet  is  the  inclusion  of  an  index  to  the  final 
DCW  product.  The  disc  label  maintains  consistency  with  the  pamphlet  by  employing  the 
Robinson  projection.  The  design  of  the  label  is  geared  toward  easy  recognition  of  the 
DCW. 

Please  review  the  contents  of  the  CD-ROM  pamphlet  and  the  other  elements  of  the  DCW 
packaging  and  comment  on  the  following  issues: 

a.  Does  the  CD-ROM  pamphlet  provide  an  informative  and  accurate  introduction  to 
the  DCW  product? 

b .  Is  the  design  of  the  packaging  visually  appealing? 


10.  DCW  Interactive  Performance.  As  you  examine  Prototype  4,  you  may  become 
frustrated  with  its  interactive  performance  response.  Those  of  you  who  have  attended  the 
DCW  design  reviews  are  aware  of  the  performance  constraints  that  the  VPF  standard,  the 
CD-ROM  media,  and  the  minimum  hardware  configuration  have  placed  on  interactive 
speed.  Since  the  development  of  the  data  standard  has  been  our  primary  goal,  our  design 
approach  has  been  to  first  develop  a  data  structure  that  suppons  direct  use  on  either  the  CD- 
ROM  media  or  on  hard  disks  of  larger  machines.  This  has  now  been  accomplished.  Our 
secondary  goal  is  to  make  the  DCW  product  on  the  CD-ROM  media  a  well-performing 
database  on  small  machines.  This  goal  needs  funher  work.  We  feel  that  performance  can 
be  improved  by  modifications  to  the  software  and  by  increasing  the  tile  size  to  reduce  the 
number  of  files.  Our  analysis  of  the  performance  of  Prototype  4  is  sbll  in  its  initial  stages. 
.A  set  of  solutions  to  improve  performance  will  be  presented  at  the  CDR  in  January.  Please 
feel  free  to  comment  on  this  issue. 


11.  Miscellaneous  Issues.  Please  use  this  space  to  list  any  other  software,  database 
or  symbolization  problems  that  you  encounter.  Since  this  is  the  final  prototype  of  the  DCW 
design  phase,  these  comments  will  be  valuable  in  our  efforts  to  create  a  product  that  is 
responsive  to  the  needs  of  its  users.  However,  it  is  important,  at  this  later  design  stage,  to 
concentrate  on  identifying  the  problems  you  encounter  rather  than  on  recommending  new 
DCW  capabilities.  Most  of  the  new  functions  that  have  been  recommended  in  the  past  have 
been  incorporated  into  Prototype  4,  and  we  are  confident  that  the  DCW  has  now  focused 
on  your  specific  requirements. 


Evaluation  of  DCW  Product  Specification 

The  Draft  Product  Specification  for  Prototype  4  defines  the  DCW  implementation  of  the 
Vector  Product  Format  and  the  content  of  the  DCW  database.  It  is  intended  to  provide  a 
detailed  description  of  the  design,  data  format,  and  content  of  the  DCW  database.  Please 
examine  the  Draft  DCW  Product  Specification  (CDRL  B002)  and  comment  on  the 
following  issues: 

a.  Does  the  Product  Specification  adequately  reflect  the  content  of  the 
Prototype  4  database? 

b .  Is  the  Product  Specification  in  compliance  with  the  content  and  format 
requirements  for  a  military  product  specification? 

c.  Does  the  Product  Specification  adequately  describe  the  technical  specifications  of 
the  DCW  database? 

Please  note  that  your  comments  on  the  Product  Specification  should  be  mailed  under 
separate  cover  to  the  address  below.  Comments  must  be  delivered  to  DMA  by  Deceir.be: 
28,  1990,  to  be  considered. 


Ms.  Pat  Hudson 
DCW  Assistant  COTR 
DMASC/WG 

3200  South  2nd  Street — Bldg.  36 
oi.  iwOuis,  Missouri  63118-3399 


USER  NEEDS  ASSESSMENT 


Questions  for  consideration 

1 .  What  is  the  hardware  and  software  environment  in  which  you  will  be  using  the  DCW? 

2 .  Are  you  using  existing  small-scale  (i.e.,  1:500,000  or  smaller)  digital  geographic  data? 

3.  What  kinds  of  existing  digital  data  are  being  used?  Please  include  level  of  detail  indicators: 
DFAD,  Level  II,  etc. 

4 .  What  are  your  current  applicadons  of  these  data? 

5.  Are  your  applications  in  an  automated  cartography-based  system  or  in  a  GIS? 

6.  What,  if  any,  problems  or  limitations  have  you  experienced  with  your  current  digital  data? 

7 .  What  types  of  applications  of  digital  geographic  data  are  you  planning  in  the  future? 

8 .  Are  there  capabilities  that  you  would  like  to  see  in  new  digital  geographic  databases? 

9 .  What,  if  any,  current  uses  of  ONC  data  do  you  currently  have  within  your  organization? 
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10.  Identify  the  potential  projects  (current  or  future)  which  arc  potential  users  of  the  DCW  (or 
DCW-likc)  diabases. 

•  Project  names  and  stage  of  development. 


-  Project  scope  (1  system'/,  5?,  10?,  207, . . .  2,0007). 

-  Dates  when  data  are  needed. 

-  Area  of  coverage  required. 

-  Hardware  (storage  media  available,  processor  capacity,  display  characteristics,  and  other 
elements  relevant  to  the  use  of  the  databases). 

-  Software  and/or  standards  to  be  used  which  impact  the  application  of  the  database  (e.g.,  all 
data  in  the  system  are  to  be  in  WGS  84, 2851  GTDB  data  structure). 
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1 1 .  Describe  the  intended  use  of  the  DCW  database.  For  example,  are  the  data  to  be  used  for: 

-  Terrain  visualization  (background  displays?  other?) 

-  Route  planning  (visibility  analysis?  avoidance  of  populated  areas?  . . .) 

-  Reconnaissance  planning  (sensor  appropriateness?) 

-  Ground  location  determination 

-  Navigation  (background?  visual  correlation?  . . .) 

-  Etc. 


12.  Please  indicate  the  information  classes  from  DCW  which  you  will  use: 

a.  Land  cover 

b.  Hydrography 

c.  Roads 

d.  Contours 

e.  Relief  and  city  tints 

f.  Special  use  airspaces 

g.  IVojection  grids 

h.  Culture  symbols 

i.  International  boundaries 

j.  Text 

k.  Aeronautical/vertical  obstructions 


1 3 .  Which  of  these  will  be  used  separately? 


14.  What  combinations  of  these  classes  will  be  used  together? 
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15.  What  preferences  do  you  have  for  DCW  data  structure?  Should  the  information  categories 
be: 

1 .  Individually  accessible? 

2.  Grouped  together? 

3 .  Some  combination  of  the  two  (specify)? 


1 6.  What  transformations  will  be  required  before  your  system  will  use  DCW  (reformatting, 
thinning . . .)? 


1 7 .  ONCs  have  contour  information.  Will  your  use  of  DCW  require  elevation  data?  If  so,  will 
these  contours  be  adequate? 


18.  If  the  contours  are  not  adequate,  what  kind  of  elevation  data  is  required?  Format? 
Resolution  level?  Accuracy? 


1 9 .  What  use  will  be  made  of  elevation  data  in  your  system? 


20.  What  transformations  will  be  performed  in  order  to  use  elevation  data? 


21.  If  you  have  identified  a  requirement  for  elevation  data  other  than  contours,  are  the  contours 
also  necessary?  If  so,  must  the  contour  and  the  other  elevation  data  match  (and  in  what 
way)? 


22.  What  types  of  output  products  do  you  plan  to  generate  and  what  are  their  graphic  display 
characteristics? 
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23.  Is  there  anything  else  that  you  will  need  from  the  DCW  to  make  effective  use  of  it  in  your 
woric? 


24.  How  will  the  DCW  fit  into  your  organizational  plans  for  geographic  data? 


2  5 .  What  recommendations  do  you  have  regarding  DCW? 


26.  What  point(s)  of  contact  in  your  organization  should  we  use  for  further  questions? 


21.  Do  you  have  any  other  questions  or  comments? 
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NOTES  ON  DCW  USER  NEEDS 


Tabl*  of  OoBtoatt 


1  Introduetloa .  1 

2  Ooolga  and  Analyala  Infotaaclon .  1 

2.1  Cesputar  Enrlrenaant .  1 

2.2  Currant  Uaa  of  SmII  Soala  Data .  1 

2.3  Currant  Uaa  of  Digital  Data .  1 

2.b  Maw  Casabllltlaa .  2 

2.3  Thanatlc  Grouplnt .  .  .  2 

2.6  Tranaferaatlon  of  DCW  Data .  4 

2.7  novation  Data  Utllltatlon .  4 

2.1  Roqulraaanta  of  DCW .  4 

2.9  Ixpaotad  Uaa  of  tha  DCW .  4 

2.10  Suggaatlena  and  laaoBoandatlona  for  ^a  DCtf .  4 

2.11  Quaatlona  about  tha  OCB .  5 

3  Llacad  Infenatlea  froa  tha  Quaatloimalra .  9 

3.1  Currant  Apolloatlona  of  Digital  Data .  S 

3.2  futura  Applleatlona  of  Digital  Data .  6 

3.3  Prejaeta  with  Potantlal  DCtf  Uaa .  7 

3.3.1  Prejaet  Daaerlptlon .  7 

3. 3. 1.1  dAOC/IWlP .  7 

3. 3. 1.2  RASC .  7 

3. 3. 1.3  ETL  Aray .  I 

3. 3. 1.4  NOAM,.  .  S 

3. 3. 1.1  STU  RE .  8 

3.3.2  Intandad  Uaa  of  DCtf  Databaaa .  8 

3.3.3  Intandad  Uaa  of  llavatlon  Data .  9 

3.3.4  Output  Produeta  to  ba  Oanoratad .  9 

4  Raapendanta .  10 


Hotaa  on  DCV  Uior  Hoods 


Jonuory  12,  1990 


Brion  0.  Holaoi 


1  Intrednetlon. 

Tho  follovlng  ia  inforaotlon  for  tho  Usor  Hoods  Assoaanonc  ropott  for  tho 
Digital  Chart  of  tho  Vorld  (DCW).  At  proaont,  tho  sourco  of  this  Information 
la  tho  aovan  rasponsos  gainod  from  a  quoatlonnalro  elreulatod  at  PRR.  Of 
thosa  rosponaoa,  fivo  wars  from  offieoa  of  tho  United  States  government,  «nd 
only  two  wore  from  foreign  offieoa.  Thla  proaonts  a  problem  In  gaining  an 
aceui  .a  aaaaaamant  of  the  foreign  user  need. 

For  ox. rapla,  one  of  tha  foreign  reapondanea  uaea  Intergraph  workacatlona  with 
tho  TIGRIS  package,  and  tha  other  waa  not  able  to  identify  tho  environment 
under  which  DCW  would  bo  used.  Only  one  other  roopondont  mentions  Intergraph 
ayatams.  and  oven  Chon  It  la  one  of  five  other  possible  systems. 

2  Design  and  Analysis  Informatlou. 

Tho  following  subsoctlont  contain  information  that  has  been  derived  from  the 
oueetlonnalre  reeponeee,  Thla  Information  la  of  moat  SBalstancs  In  the  DCW 
daelgn  effort. 


2.1  Computaz  Inwlronnent. 

Three  general  computer  environments  represent  the  majority  of  posalbla  lystena 
under  which  the  DCW  will  ba  uaad.‘  j  j  r  j 


PC  ayatam  (286)  operating  in  a  DOS  environment 
VAX  ayatem  operating  in  a  VMS  or  UNIX  anvironmant 
SUN  system  operating  In  a  UNIX  environment 

The  raspondanta  also  mention  higher  level  PC  ayatemt  (386)  operating  In  UNIX, 
and  Intergraph  workatationa.  Mention  waa  also  made  of  HP900B,  IBM  malnfraat, 
and  Apollo  computer  systama. 

While  moat  raspondants  did  not  list  tha  software  packages  under  which  they 
operate,  a  few  did  mention  use  and  experimentation  with  ARC/INFO,  CRASS,  and 
In-house  aystems.  TIGRIS,  MOSS.  System  9.  MapGrsflx,  PACE,  end  SPANS  were 
Alto  iiiCod« 


Moat  reepondente  Indicated  that  they  use  both  CIS  and  automated 
carcography-baaad  aofcwara.  Tha  uaa  of  In-houee  software  and  software 
currently  under  development  was  also  ditcueeed  in  eevaral  of  the  responses. 

2.2  Current  Use  of  Small  Seele  Dote. 


Most  respondents  stated  that  they  currently  uead  email  ecale  data  of  one  kind 
or  another,  or  that  they  planned  to  use  the  DCW  aa  a  amall  scale  source. 

'^NC.  and  CNC.  Raepondants  listed 

uses  of  ONCs  aa  high-level  planning  aide,  as  background  for  other  maps,  as  a 

^2^*'  a"**  **  a  source  for  boundary  Information.  One 
wrld-ilde*^coverage^'*'**^  pr*f*cred  source  for 


2.3  Current  Dae  of  Digital  Data. 

V?**  Dy  Ch«  raspondenti,  DIED  levels  I  and  II, 

2  5  levels  I  and  II  ware  Hated  by  moat  raspondanta .  WDB  II,  ADRG,  UVS 

listed.  Also  mentioned  were  DFAD  IC.  DFAD  3C.  DVOD.  and  a 
boat  of  other  leas  popular  data  baaaa, 

?'•  *5*  llaltatlpns  axparltncad  with  these  data  baaes  are  wide 

ranged.  They  deal  with  tha  format  and  specification  of  tho  data  th«  dat* 
concent,  and  dlffleuXtlea  In  the  procaaalng  of  tha  data,  ’ 

Lack  of  quality  control  of  format  and  apaclflcatlon: 


Syataa  dapandaat  atoraga  format  and  atruetura;  difficult  to  toporc  and 
expert:  difficult  to  davalep  atandard  aefewara;  unatructurad  and  product 
tpaelf ie ; 

Strueturad  for  the  preduetlon  of  mapa  and  eharta,  and  tharafera  net 
phyaleally  eentinuoua; 

Slow  procaaaing  and  dlaplay  duo  to  raacar  aceraia  or  high  attribution; 
alow  procaaaing  duo  to  atoraga  atruetura  and  voluaa; 

Inadequate  attribution; 

Inauffleienc  reaelueien; 

Xnauffieient  eovaraaa;  unavailability  of  data  over  foreign  areaa;  poor 
content  for  areaa  or  aparae  data  availability; 

Canarallxation  llaitatiena; 

9oma  of  thaao  eooaenta  eonfllet  baeauae  they  come  from  aaveral  different 
aoureea.  For  exasple.  aoftware  that  operataa  on  data  that  la  atored  in  an 
open  or  general  format,  will  alao  bo  general,  which  will  reaule  in  longer 
proceoalnc  and  dlaplay  tinea.  Thia  ia  alae  true  of  aoftware  that  ouat  operate 
on  data  or  high  voluma,  high  ateributien,  and/or  high  reaolutlon.  Product 
apeeitic  aefewara  tanda  to  preeaaa  data  more  rapidly. 


2.4 

The 


Raw  Capabilieiea. 

following  are  eapabllltiea  dealred/by  the  raapendanta. 

doala  free;  ability  to  chance  acalea  with  appropriate  ganaralization  of 
feaeurea;  contain  multiple  lavala  of  rapraajntation; 

Improved  netheda  of  tracking  throughout  aceeaa;  built 'In 

aourea  documentation  (date  of  Infomaeion,  accuracy,  origin,  input  acale, 
ate...):  lineage  and  quality  annotation; 

Ugaiihility  with  other  producta;  eer.'.on  format;  uaa  of  atandfxd  query 
atnieeurea; 


-Sloplieicy  In  atruetura  and  organization  for  eaae  In  cuatom  accaaa;  eaae 
of  uaa; 

Conaiatency  batwaan  acalea; 
l.egieally  aeanleaa  and  continuoua; 

^Ide  area  of  coverage; 

Addition  of  aynthaeie  featuraa; 

Afaar  Indexea  to  facilitate  aceeaa  to  data; 

Ability  to  aupport  high  quality,  color,  paper  output; 

Better  aeareh  apeed; 

Preaervatlon  of 
Automatic  product  generation; 

Better  raacar  to  vector  and  automated  topology  generation; 


2.S  Thematic  Orouping. 

The  themea  proaented  in  the  queatlonnalre  appeared  to  agree  with  moat  of  the 
raapendanta.  Moat  indicated  that  they  ware  likely  to  uaa  all  of  the  thamaa  In 
Bome  way.  One  commencad  that  special  use  eirspecaa  and  aeroneucicei/verelcel 


obMCraetlenM  vould  only  bo  uooful  if  tho  Information  vaa  currant,  and  tnochtr 
tcattd  that  thay  would  bo  tha  laaat  uaaful.  Anothor  raapondent  atatod  that 
apaeLtl  uaa  alraptcaM  and  projaeelen  grids  vould  not  ba  uaaful. 

Tha  raapondants  all  felt  that  tha  data  would  ba  Boat  uaaful  if  thaoaa  were  not 
groupad  togathar.^  Moat  raapondonta  that  tha  uaaa  of  tha  data  will  be  vide 
apraad,  and  thua  raquira  a  more  general  storage  and  that  grouping  tha  data 
impliaa  a  apaolfio  uaa. 


The  following  ia  a  Hat  of  tha  grouplnga  that  llluatrato  tha  vaya  in  which  cha 
reapondanta  expect  to  uaa  tha  data, 

a  b  land  cover,  hydrography; 

a  b  c  a  h  t  land  cover,  hydrography,  roada,  relief  and  city  tints, 
culture  aynbola,  Intomational  boundaries; 


a  b  c  a  k 


land  cover,  hydrography,  roada.  raliaf  and  city  tints, 
aaronautieal/vartieal  obatruetions ; 


a  b  e  g  i 

a  b  c  h 

a  b  c  1 

a  b  e  1  k 

a  b  d 

•  J 

b  o 
boh 
b  0  1  J 

b  e  k 

b  d  a 

e  a  f  1  k 


land  cover,  hydrography,  roada,  projection  grids, 
intomational  boundarlaa; 

land  cover,  hydrography,  roada,  culture  aynbola; 

land  cover,  hydrography,  roads,  international  boundaries; 

land  cover,  hydrography,  roads,  international  boundaries, 
aerenaucieal/vertlcal  obatruotlona ; 

land  cover,  hydrography,  contours; 

land  cover,  text; 

hydrography,  roads; 

hydrography,  roada,  culture  aynbola; 

hydrography,  roada,  international  boundaries,  text; 

hydrography,  roads,  aaronautieal/vartieal  obstructions; 

hydrography,  contours,  relief  and  city  tinea; 

roada,  relief  and  city  tints,  special  use  airspaces, 
intemaeionai  boundaries,  aeronautical/vertical 
obstructions; 


c  h 

d  g  1  k 
d  k 

a  f  h  J  k 
f  1  k 


roada,  culture  aynbola; 

contours,  projection  grid,  international  boundaries, 
aeronautical/vertical  obstructions; 

contours,  aeronautical/vertical  obetructlons ; 

relief  and  city  tints,  special  use  airspaces,  culture 
symbols,  text,  aeronautical/vertical  obstrueeiens; 

special  uaa  airspaces,  intematlonal  boundaries, 
aeronautical/vertical  obstructions ; 


Though  there  are  valid  reasons  for  grouping  acne  themes  of  data  together,  the 
capability  to  add  or  subtract  one  theme  from  a  group  of  themes  must  exist.  It 
seems  that  this  along  with  the  fact  chat  the  decemination  of  the  most  useful 
groupings  ia  impractical  lead  most  respondents  to  prefer  tho  themes  be  scored 
individually. 


1  One  respondent  felt  that  some  combination  of  grouping  and  individual  storage 
might  be  used. 


2.(  Truiafoxvatlon  ot  DCV  D*ta. 

The  ratpondants  lltcad  aavaral  typaa  of  data  tranalatlon  that  oi(ht  naad  to  ba 

?arforaad  on  tho  DCV  data  bafota  thay  would  ba  abla  to  maka  uaa  of  it.  Moat 
latad  tha  raatruotuxlnc  of  CO  data  to  an  on-Ilna/GlS  databaaa.  Thla  ahowa 
that  tha  raapondanta  do  not  Intand  to  prooaaa  tha  data  dlraetly  off  of  tha  CD 
or  In  DCV  foraat, 

Thlnnlnc  and  eoapraaaion  of  tha  data  wata  alao  llitad,  along  with  format 
compaction,  taaaallation,  projaetlon  eoocdlnata  eonvaralon,  and  attrlbuta 
coding  and  unit  tranalatlon.  Ona  raapondant  suggaatad  that  a  atandard 
ganaralizatlon  and  thinning  rouclna  ba  auppllad  with  tha  data. 

2.7  Elawatlon  Data  Otlllaatlon. 

All  raapondanta  indicated  that  they  requlra  alavatlon  data.  All  but  one 
indicated  that  tha  ONC  contours  would  not  ba  anough.  DIED  lavala  I  and  11,  or 
other  DTK,  ware  llatad  aa  altamata  aourcaa  for  alavatlon  data.  Moat 
raapondanta  Indicated  that  thay  daairad  the  ONC  contours  Included  In  the  DCV 
data,  and  chat  tha  contour  data  should  match  tha  alavatlon  data  over  the  same 
extant. 

Soma  of  the  raapondanta  indicated  that  tha  format  and  resolution  of  tho  DTED 
products  ware  aceaptablo  because  of  their  wide  spread  uaa.  These  same 
raapondanta  vara  mixed  about  the  accuracy  of  tho  products,  sighting  that 
greater  accuracy  would  bo  required  for  large  scale  data. 

2.1  Raqulramanta  of  DCV. 

Standardize  format/atructuro.  glossary,  and  Indexes  of  digital  data; 

A  gazetteer  capability  to  detarmina  the  location  of  named  places ; 

A  names  database  to  support  produot  genaretlon; 

A  source  idenciflcaclon  database  to  support  map  indexing; 

Cood  user  documantatlon; 

User  orlantod  preduet  format  (Indexed  data); 

Standardized  utility  software; 

Ability  to  display  associated  symbology; 

2.1  Expected  Uaa  of  the  DCV. 
small  scala  applications; 

repleoe  VDB  ZI  as  world-wide  CIS  eouroe  data  with  better  resolution; 
serve  as  a  standard  for  large  scale  databasea; 
map  Index; 

conversion  to  In-housa  format  and  used  for  product  generation; 
to  evaluate  applications  for  digital  MC&G  data; 

as  a  storage  standard  chat  will  minimize  storage  space,  and  Improve 
efficiency  In  data  distribution; 

2.10  Suggestions  and  Racommanda cions  for  tha  DCV. 

The  following  are  suggestions  and  recommendations  for  the  DCU.  The  comments 
are  preaented  as  they  appesred  as  reaponsea,  when  poaalble. 

The  dletrlbutlon  media  ehould  not  ba  restricted  to  CD  ROM.  Support  of 
traditional  magnetic  madia  should  bo  part  of  tha  early  Ufa  cycla  of  thi* 
product.  ' 


Tht  initial  CAtgat  ■yataaa  hmi  baan  stacad  to  ba  PC  with  MS-DOS.  Tha 
product  protocypaa  ahould  alao  ba  available  for  PC  with  UNIX  oparatlna 
lyataa. 

Tha  DCV  databaaa  ahould  alao  ba  availabla  on  altamatlve  nedia  euch  aa 
9-traek  tapa  and  quartar-ineh  eartridgaa  (for  SUN  ayatana).  It  would 
alao  ba  uaaful  if  ralaaaad  in  a  nuabar  of  popular  formaca  which  have 
acted  aa  da  facto  atandarda,  aueh  as  ARC/INFO. 

Tha  hardcopy  produeta  of  the  prototype  digital  data  ahould  ba  diacribuced 
with  tha  prototypaa  to  aupport  avaluatlon. 

Tha  draft  apeeificatlona  ahould  ba  distributed  as  aeon  as  poaaiblo. 

A  faatura  attribution  table  that  aapa  syabol  and  color  oodaa  to  ONC 
aoaeifieationa  could  ba  used  as  a  basallna  to  standardize  feature 
diaplaya  for  cross  ays tea  eeeparlaen  and  evaluation. 

Database  ahould  have  a  ganarle  (not  product  apaclfie)  fora. 

Tha  D(W  should  adopt  DClVC  topological  vector  axchanga  foraat  and  ISO 
8211  thus  giving  tha  standard  aoaa  real  aneeuragaaant . 

Use  FACC  rather  than  FACS. 

Tha  project  should  try  to  address  standards  for  large  aoalaa  up  to  1;50K; 
some  of  these  standards  may  have  little  relevance  to  a  data  aat  at  1:1M, 
but  wa  baliava  that  this  is  an  Inportant  part  of  tha  project. 


A  topological  structure  nay 

Application  software  ahould  allow  for  tha  etrlpplng  out' of  topological 
relationships  and  thus  reduce  the  oomplsxlty  of  the  data. 

Tha  acconpanying  softwara  could  usefully  include  tha  facility  to 
do^grada  tha  data  on  output  (as  a  user  option)  to  a  chain-node  structure 
and  to  “spaghetti." 

2.11  Quastiona  About  tha  BCV. 

Will  tha  product  and  standard  ba  axtandabla  by  tha  use?  What  nachanlsa 
exists  to  do  so? 

How  will  DCW  data  ba  compatible  with  other  digital  data  products 
raaulting  from  tha  modernization  program  since  DCW  will  be  derived  from 
"aging"  hardcopy  maps? 

How  will  color  coding  and  symbology  ba  handled  in  tha  database? 

3  Listed  Information  from  tha  Quastlennalra. 

The  following  aubsectlona  Include  information  taken  more  or  less  directly  from 
the  queationMiras.  This  infonstion  does  not  allow  for  analysis  and/or  does 
not  support  tha  first  stages  of  tha  design  effort.  ^ 

3.1  Currant  Applieatiene  of  Digital  Data. 

The  following  are  the  infonsatlon  drawn  from  question  4, , . 

Spatial  analvsls  support  for  Intelligence  analysts.  This  Includes  such 
the  applications  as;  .  situation  displays,  cross  country  movement,  mission 
planning,  route  prsdlotlons,  threat  anvalopas,  and  visibility. 

Data  integration  and  evaluation. 

Database  server  for  laboratory  applications  software  syscams. 

Background  display. 

Ceographio  data  analysis. 


not  be  necessary  for  all  applications. 


allow  for  tha  strl 


out  of  topological 
data. 


Ov«xvi«v  and  Indaxlng  for  rotrioval  of  DPPDB. 

Prodxietloa  of  high  quality,  full  color  papar  map  products. 

Qulok  map  dlaplay  &  visual  analyala.  roam,  aooa,  oto. 

Tarrain  aodaling  and  ralatad  tarraln  atudlaa.  Environaancal  nodallng. 
Mobility  studios. 

Ganaral  thanatle  map  craatlon  on  aealas  ranging  from  global  to  urban, 
Scoraga  &  racrlaval  of  gaographlcally  rafaranead  attribute  Information. 
Cultural  &  natural  faatura  query  and  ratrlaval. 

Noewerk  atudlaa,  ■ulclvarlata  modeling. 

Map  and  chart  production. 

Davalopmantal  work  In  tarrain  analysis. 

Tactical  Doclalon  Alda. 

Tarrain  Analysis. 

Map  Baekgrotinda . 

Examination  of  raqulramanta  for  digital  MC&G  data. 

Skall  aeale  non-navlgatlonal  paper  graphics. 

Incorporation  Into  command  ayataa  type  applleations. 

TPC  production. 

Cooparatlva  production. 

Prototype  davalepmant. 

3.2  Putura  Applications  of  Digital  Data... 

Ths  following  are  the  information  drawn  from  question  7... 

Putura  plans  for  spatial  data  will  entail  the  integration  of  currant 
applications  which  will  result  In  Intarmadlata  products  and  the  autemacsd 
exploitation  of  those  products  through  processes  of  spatial  reasoning  and 
expert  systems.  In  more  detail  we  will  be  using  digital  geographic  data 
for:  area  limitations,  cross  country  movement,  transportation  network 
analysis,  and  terrain  analysis,  among  others. 

List:  (1)  Mors  extensive  and  complex  network  analysis,  (2)  More 
detailed  display  and  query  of  features.  (3)  Using  CIS  as  the  Interfacs 
to  store,  query,  and  retrieve  voluminous  and  complex  information  which 
can  be  tlao  to  a  location.  (4)  Answering  quick  questlona  such  as: 

vhsrs  is  _ 7  whst  is  at  location _ 7  where  are  all  of  the 

within  an  area?  what  la  tha  area  of  7 .  ate.  The  same  types  of 

questions  that  may  ba  asked  of  papar  mapa,  but  raqulra  eensldarabla  time 
and  effort  In  anawarlng  ualng  tna  paper  madia.  (5}  Incorporating 
temporal  faetera.  Change  dataetien. 

Apart  from  centlnuad  use  for  map  and  chart  production,  it  la  envisaged 
that  data  will  ba  used  In  command  and  control  syatama,  tarrain  analysis 
ayatsms,  Infrastructure  daelsion  support  systems,  and  In  Intalllgant 

weapons  systsms. 

List:  Mission  Plsnnlng/Rehsarsal,  Training  Simulators,  Tactical  Decision 
Alda ,  Map  Backgrounds , 

Expanded  uaa  within  Navy  operations.  Attempting  to  sducsts  Navy  wespone 
&  planning  system  dsvslopars  on  benefits  of  using  digital  data. 
Applications  range  from  mission  planning  support  to  weapon  system 
targeting  and  guidance.  Anticipate  heavy  uaa  within  Amphibious  srtns. 


r«qulrM«nCB . 

At  50K:  Terrain  Anelyale  end  diepley  product*  (Topologlcel) .  At  230K: 
Terrain  Anelysi*  end  dlepley  products  (Topologleel) .  At  500K:  Dl*pl*y 
product  (Topologleel).  At  1;IM  DCU 


3.3  Projects  with  Potential  OCV  Os*. 

The  follovlng  era  the  Infometion  drevn  fron  quascione  10,  11,  19,  end  22... 


3.3.1  Project  Deseripcion. 

3. 3. 1.1  tADC/XllP. 

CAT5S  Dlcltel  Cereographlo  Applications,  (OCA),  (prototype  laboratory) ; 
Air  Flight  Test  Routes;  AfiCCC  III  (Airborne  Battlefield  Cooaend  end 
Control  Canter  Phase  III);  C-17A  Intratheatsr  Transport  Aircraft;  CHARPS 

(Conventional  Mating  &  Ranging  Planning  Syseea:  CMAo  (Cruise  Missile _ 

Advene*  Guidance);  DlIS  (Digital  Inagsry  Transaleelon  Systaa);  EO-LOROPS 
(Ground  Exploitation  Systaa  for  Bleecro-Optleel  Long  Range  Systea):  LS 
(Lantlm  Slaulator);  COMBAT  TAL  MC‘130H  Production;  OBMM  (On  Board 
Mlsaien  Kanegeaanth  RAILS  I  (Relational  Analysis  of  Intemattad  Linkage* 
Systaa  Phase  I);  Special  Oparaelens;  tfS-428A  XX  (Tactical  Infomstlon 
Processing  and  Interpretation  (TXPI)/IIS);  TMDPS  (Target  Material  Digital 
Pradlotlon  Systea);  TRMMS  (TR«i  Mission  Managsaent  Systaa) 

DCA  exists  as  on*  eystem  that  Is  a  teat  bad  for  technology  dcvelopaent 
and  transfer  into  nuaerous  other  Air  Force  syeteas. 

Dae*  Is  needed  as  soon  as  possible  for  evaluation.  Project  exploitation 
should  begin  In  Py90<91. 

The  world  would  be  ideal,  however,  the  Western  healspher*  should  have 
first  priority,  Soae  projects  will  require  the  follovlng  areas  of 
coverage:  EUROPE  (4  degress  X  6  DEGRESS);  KOREA  (2  dearees  X  2 
degrees):  CENTRAL  AMERICA  (2  degrees  X  2  degrees);  SOOTH  WEST  ASIA  (2 
degrees  X  2  degrees);  NSIXIS  RANGE  (6  degress  X  6  degrees);  FORT  DRUM, 
NY  (2  degrees  X  2  degrees):  FORT  HOOD,  TX  (TTD). 


3. 3.1.2  IA8C. 

PREFARE  (RASC);  MCXS  (RASC) ;  AUSTACCS  rA.ietrallan  Aray> 

The  FREFARE  project  la  at  a  concsptuac'oesign  scag*  ana  due  for 
Introduction  In  the  ald-1990t.  Tn*  systea  will  contain  a  nunber  of  data 
capture  eoaponents  including  phetograassatry,  scanning,  end  Input  from 
reaotely  sensed  capture.  It  is  expected  that  the  systea  will  contain  an 
extensive  range  of  dsts  editing,  vslidatlen,  end  foraattlnf  functions. 

The  systea  auit  have  tha  capability  of  aanaglng  data  over  RASvy's  area  of 
defsnea  reaponaiblllty.  Hardware  and  software  eonflsurstlons  era  yet  to 
be  dstsralnsd,  however,  It  Is  snvissgsd  that  data  will  be  In  a  range  of 
reference  systsas  end  that  espshilltles  must  be  provided  to  transform 
data  for  a  range  of  users. 

The  MCXS  project  Is  at  a  prototype  scags.  A  nuabar  of  conrasrclal  CISs 
ara  balng  uaad  in  Darwin  with  applications  developed  for  users  in  ths 
specif ie  arse. 


3. 3. 1.3  BTL  Axay. 

Joint  Chlof*  o£  Staff  J8  Oltoctotato  Amy  World  Wldo  Hlllcary  Command  and 
Control  Syicoa  Intalllgenea  Throat  Analyali  Contar. 

100-t-  ayatama,  data  accaptabla  In  1992,  worldwida  eovaraga. 

HV:  a.  SCSI  Tapa  Dxivo,  200>Mbyta  hard  dlak;  b.  Unix  workatation,  2*3 
HIPS:  e.  4 >24  bit  diaplaya;  d.  thara  ia  a  ahortaga  of  drivara  for  UNIX 
CO'ROM  drivea. 

SV:  VGS  84  with  oapabilicy  to  oonvart  to  UTM  &  KCRS. 

Standatda:  Any  atandarda  adoptad  by  DoD  and/or  Army  up  through  tha  DCU 
dalivary  tima  xraaa  will  hava  iopaeta. 

3. 3. 1.4  HOAII. 

Digital  MC&C  Analyaia  Program  (ongoing):  Tactical  Environmantal  Support 
Syataa  (under  davalopnant) ;  Tactical  Air  Miaaion  Planning  Syseaa  (undar 
davaiopmant) . 

worldwida  eovaraga,  PCa  and  mini  proeaaiora,  and  highland  graphiea. 

3. 3.1.3  ITU  tl. 

a,  Advancad  Miaaion  Planning  Aid  (AMPA) .  Approx imataly  30  ayatema  with 
ISO  1  Oct  1990.  Covaraga  raqulrad  for  routaa:  Europa 'UK- Canada; 
UK-Baliza;  Baliza  araa  including  aouthem  USA.  Tha  hardwara  ia  to  ba 
halicoptar/vahlela  cranaporcabla,  eapaoit^  not  yac  known  but  oApaccad  to 
ba  vary  latga  with  hard  diak  atoraga. 

b.  Europaan  Fightar  Aircraft  (EFA).  Mumbart  of  aircraft  ayatama  not 
known  but  axpaetad  to  ba  aavaral  nundrad.  ISO  1998.  Araa  raouirad  la 
aatimatad  to  ba  that  covarad  by  ONCo:  E>16,  17,  18,  and  19;  P«16,  17, 

18,  19,  and  22;  G«18,  19,  20,  and  21.  Syatama  will  ba  aircraft  mounted 
but  nothing  known  of  hardvara/aoftwara. 

e.  EFA  Miaaion  Simulator.  ISO  1997.  No  othar  information  available . 

d.  Saoond  ganaratlon  for  data  gatharlng  and  analyaia.  Raqulraa 

amail  acala  nap  dacabaaa.  {^o  other  inzoraation  available. 

Dafanca  Geographic  Oatabaaa:  (1)  Will  hold  3  data  aata  (1;50>I:250, 
1:300,  1:1M);  (2)  TIGRIS  (object  oriented)  logical  data  atructure;  (3) 

DGZVG  topological  vector  exchange  format;  (4)  FACC  coding;  (3)  VCS  84 
gaodatie  reference. 

3.3.2  Itttandod  Vaa  of  DCff  DaCabaaa. 

Baaed  on  functional  requirenenta  analyaia,  all  of  the  applicationa  Hated 
above  are  intended  uaaa.  In  addition  to  tha  applicationa,  however,  there 
will  ba  tha  need  for  ganaratad  aynthetic  faaturaa  auch  aa  threat  araaa, 
nobility,  napa,  and  miaaion  routaa  to  ba  added  to  tha  data  baaa  to  be 
treated  aa  any  othar  faacurea.  **  Interfacing  with  imagery 
axploltation/intalliganca  applicationa.  **  Intarviaibility. 

Repliaa  to  thia  quaation  apply  only  to  tha  DCV  digital  ONC  product  and 
not  to  potential  larger  acala  produeta  uaing  tha  DCV  aeandard;  (1) 
terrain  viauallzatioQ,  with  or  without  cultural  faaturaa,  aa  tha  primary 
aublact  or  aa  backdrop  for  other  infomation;  (2)  route  planning, 
vlaibllity  analyaia;  (3)  reconnaiaaanea  planning;  (4)  locational 
dacamination;  (3)  briafinga  and  altuational  diaplaya;  (6)  locating, 
plotting,  information  overlay;  (7)  network  atudiaa;  (8)  attribute 
query:  (9)  war-gaming  axarciaaa. 


Lift:  [from  quoatlon]  ttxraln  vi«u«llzaclon,  rout*  planning, 
rooomtaltaanoa  planning,  navigation,  fplua]  priurily  «  oap  background, 
and  apaelal  indax  to  larger  aeala  preducta. 

LiaC:  [from  tha  (jueation]  terrain  visualization,  route  planning, 
reoonnaiaaanca  planning,  ground  location  datarminacion,  and  navigation  to 
aoma  extent  •  mostly  background  diaplay  for  electronic  chart.  DCW  will 
ba  uasd  within  both  miaaion  planning  ayatema  and  to  support  weapons 
ayatams  and  C&I  for  background  display.  Applications  Includa 
lina*ef*aight,  caecioal  amphibious  miaaion  planning,  facilities  manager, 
and  other  phases  of  tactical  mission  planning. 

Our  applieations  relate  to  marina  navigacien  and  naval  command  and 
control.  Uaa,  eharafora,  dapands  on  the  eentsnt.  quality  and  currency  of 
the  hydrographic  elements  and  coastal  topography. 

3.3.3  Intended  Uaa  of  Ilavatien  Data. 

Viaibllity  (line  of  eight  masking). 

Computation  of  foaturs  elovation. 

Profiles. 

Slope  computation. 

Diaplay  (hill  shading) . 

Mobility. 

Perspaotive  views  (30). 

Production  of  standard  map  products. 

Conatruotion  of  digital  dafancs  products. 

Lina  of  Sight 
Terrain  Masking 
Air/Ground  Avenues  of  approach 
3  Oimansional  parapaetiva  views 
Slope  Maps 

Lina  of  eight  calculatlona 
Terrain  visualiration 
Terrain  masking 
Mobility  analysis. 

Small  aeala  charting  (contour  form). 

3.3.4  Output  Products  to  be  Generated. 

Situation  displaya 

Visibility  displays 
Avenues  of  approach 
Interdiction  points 
Mobility  polygons 
Maw  AOl  products 
Color  by  feature 

Overlay  information  (Intelligence,  routes,  hydro) 

Mission  planning  routes 


SyBbolis«4  oultuTAl  fMturaa 

fariptstlTvi 

OXS  qu«t7  r«ipoiui«a 

Frefilaa 

Daeonfllet  faaturaa 
Standard  oolora 

USAf  ■illeary  applieaeiena  atippore  data 

Tha  araBhlo  dlaplay  xaqulxaaanta  xanga  fxea  txadltional  sap  aTuboltzatlon 
to  highly  atyllaad  aehaaatla  pattama.  Tha  only  display  cenaerainta  ara 
tha  lulM  of  tha  display  dsTiaa. 

Cooposlta  flla  positlToa  (nagaciyas)  for  uaa  In  ehaxt  production 
(produead  on  raatat  scan  aquipaane). 

Snail  aeala  papar  graphics,  poaaihly  including  navigational  eharti. 
CoMand  and  eentxel  ays  tana. 


Respondents ; 

-  Captain  Marvin  Marquez,  USAF,  Rome  Air  Development  Center 

Mark  S.  Johnson,  Central  Intelligence  Agency 

Lieutenant  Colonel  R.  Blackburn,  Directorate  of  Survey, 
Army,  Bendigo,  Australia) 

Major  R.  Williams,  Army  Survey  Regiment,  Bendigo,  Australia 

Juan  Perez,  U.S.  Army,  Engineer  Topographic  Laboratory 
Chris  Moscoso,  U.S.  Army,  Engineer  Topographic  Laboratory 

Dr.  D.  Drinkwater,  Hydrographic  Office,  United  Kingdom 
Ian  Smith,  Military  Survey,  United  Kingdom 

John  Breckenridge ,  U.S.  Naval  Oceanographic  &  Atmospheric 
Research  Laboratory 
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